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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the protocol details for the messaging service within the IP Multimedia CN Subsystem 
(IMS) based on the Session Initiation Protocol (SIP), the Session Description Protocol (SDP) and, the Message Session 
Relay Protocol (MSRP) . The document covers immediate messaging, session based messaging and session-based 
messaging conferences, as described in 3GPP TS 22.340. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP, SDP and, MSRP, either directly, or as modified by 3GPP TS 24.229. 

The present document is applicable to Application Servers (ASs) , Media Resource Function Controllers (MRFCs), 
Media Resource Function Processors (MRFPs) and to User Equipment (UE) providing messaging capabilities. 

This document does not cover the signalling between a MRFC and a MRFP. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

IsComposing information This is a term used to indicate that an indication is sent to the communicating user when 

a user in entering a new message. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 22.340 [11] apply: 

Immediate messaging 

Session based messaging 

Session based messaging conferences 
For the purposes of the present document, the [following] terms and definitions given in RFC 4975 [9] apply: 

Host 

Page-mode messaging 

Session inactivity timer 

Session-mode messaging 

Session-mode messaging conferences 

Visitor 
For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.147 [10] apply: 

Conferencing Application Server 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

CN Core Network 

DM Data manipulator 

DMS Data manipulation server 

IM IP Multimedia 

IMS IP Multimedia CN subsystem 
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IP 

MRFC 

MRFP 

MSRP 

SBLP 

SDP 

SIP 

UE 

URL 



Internet Protocol 

Media Resource Function Controllers 
Media Resource Function Processors 
Message Session Relay Protocol 
Service Based Local Policy 
Session Description Protocol 
Session Initiation Protocol 
User Equipment 
Uniform Resource Locator 



Messaging overview 



The basic services for the IP Multimedia core network Subsystem (IMS), as defined in 3GPP TS 24.229 [5], allow a 
user to initiate, modify and terminate media sessions using the Session Initiation Protocol, as defined in RFC 3261 [7]. 
Although these basic mechanisms already allow the exchange of instant messaging information using SIP, this 
functionality can be extended to provide a richer service within the IMS. 

The messaging service within the IM CN subsystem provides the means for a user to send or receive single messages 
immediately to / from another user and to create and participate in a messaging conference with one ore more other 
users. Participants to such message based communication may be internal or external to the home network. 

When to use an immediate message and when to use a session-based messaging session will depend on the application. 

NOTE: Some participants may always use session-based messaging, while others may use immediate messaging 
or a combination of session-based messaging and immediate messaging dependant of the characteristics 
of the messaging session. The criteria are implementation and application specific. 

For immediate messaging the procedures for page-mode messaging, as defined in RFC 3428 [8] or for session-mode 
messaging, as defined in RFC 4975 [9], draft-ietf-simple-msrp-cema [19] and RFC 6135 [18] are utilized. When to use 
an page-mode messaging and when to use session-mode messaging session for the purpose of immediate messaging 
will depend on the application. 

For session-based messaging and session-based messaging conferences, the Message Session Relay Protocol (MSRP) is 
utilized to transport messages. 

The architecture for the 3GPP messaging is specified in 3GPP TS 23.228 [6] and 3GPP TS 23.218 [3]. The 3GPP 
recommended media formats and codecs are specified in 3GPP TS 26.141 [14]. The 3GPP2 recommended media 
formats and codecs are specified in 3GPP2 C.S0050-B [17]. 

The functional split for session-mode messaging between an AS, MRFC and MRFP is that same as that described in 
clause 4 in 3GPP TS 24.147 [10] for SIP based conferences. The functional split between the AS, MRFC and MRFP for 
page-model messaging is out of scope of the present document. 



Protocol using SIP for page-mode messaging 



5.1 



Introduction 



5.1 .1 Sending immediate message to multiple recipients 

The UE may be able to send a single immediate message to multiple recipients by including in the MESSAGE request 
the list of URIs (i.e., URI-list) that identify the intended recipients. 

The UE shall create a MESSAGE request in accordance with 3GPP TS 24.229 [5], and it shall also include a multipart 
body in the MESSAGE request. The Request- URI shall be set to the SIP URI of the Application Server that implements 
the role of the List Server. The multipart body shall contain the body carrying the URI-list (in the XML format) whose 
Content-Disposition type is 'recipient-list', and the body that contains the immediate message payload as specified in the 
RFC 5365 [12]. 

The handling of the received response shall be in accordance with 3GPP TS 24.229 [5]. 
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5.2 Functional entities 

5.2.1 User Equipment (UE) 

For the purpose of page-mode messaging, the UE shall implement the role of a Participant as described in 
subclause 5.3.1. 

5.2.2 Application Server (AS) 

As the functional split for the purposes of page mode messaging between the AS and the MRFC is out of scope of the 
present document, the procedures are described for a combined AS and MRFC. The AS and MRFC may either be 
collocated, or interoperate using a proprietary protocol and a proprietary functional split. 

For the purpose of page-mode messaging, an Application Server may implement the role of a List Server as described 
in subclause 5.3.3. An Application Server may implement the role of a Participant as described in subclause 5.3.1 

5.2.3 IVIedia Resource Function Controller (MRFC) 

As the function split for the purposes of page mode messaging between the MRFC and the AS is out of scope of the 
present document, the procedures for the MRFC are described together with those for the AS in subclause 5.2.2. 

5.3 Role 

5.3.1 Participant 

5.3.1.1 General 

For the purpose of page-mode messaging a participant will send a page-mode message using a SIP MESSAGE request 
as defined in RFC 3428 [8] to another participant. 

5.3.1 .2 Sending of an immediate message 

When sending a page-mode message to another participant or to a list server, the participant shall construct and send a 
MESSAGE request in accordance with RFC 3428 [8] and subclause 5.1.2A.1 of 3GPP TS 24.229 [5]. 

The participant may include in a MESSAGE request an isComposing status message as defined in RFC 3994 [13]. 

The participant shall stop transmitting isComposing status messages if the participant receives a 415 (Unsupported 
Media Type) status code in a response to a MESSAGE request containing the status indication. 

The Request URI shall either be: 

the URI of the other participant; or 

a PSI identifying a group. 

5.3.1 .3 Receiving an immediate message 

Upon receipt of a MESSAGE request, the participant shall perform the procedures as described in RFC 3428 [8] and 
subclause 5.1.2A.2 of 3GPP TS 24.229 [5]. 

NOTE: A MESSAGE request can be used for applications other than immediate messaging (e.g. 

3GPP TS 23.228 [6] subclause 5.4.9), and the handling of received MESSAGE requests for such 
applications is outside the scope of this specification. 
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5.3.1 .4 Consent to list server distribution 

A participant capable of receiving message requests should support the requirements of a recipient defined in 
RFC 5360 [16]. 

5.3.2 Application Server (AS) 

5.3.2.1 Receiving an immediate message for unregistered Public User Identity 

When an immediate message destined for an unregistered Public User Identity arrives at the user's home network, the I- 
CSCF and S-CSCF perform the actions as specified in 3GPP TS 24.229 [5]. 

If the Public User Identity has services related to unregistered state activated (i.e., hold the MESSAGE request 
temporarily in the network.), the MESSAGE request will be routed to an AS, which processes the request further on. 
The AS may then hold the MESSAGE request and deliver the MESSAGE request when either the UE becomes 
reachable or the validity of the message expires as specified in RFC 3428 [8]. 

5.3.3 List Server 

5.3.3.1 List server originating case 

In addition to the procedure specified in subclause 5.3.3.2 the list server shall follow the procedures of 
3GPP TS 24.229 [5] subclause 5.7.3 when acting as an originating UA. 

The PSI is used to address a predefined list of URIs. 

The list server shall send a MESSAGE request to each of the entries in the predefined URI Ust. For each of MESSAGE 
requests the list server shall populate the header fields as follows: 

a) the Request URI header fields set to the URI of one of the entries of the predefined URI list; 

b) the From header field set to the same value as the From header field (excluding the "tag" parameter) that was 
received in the incoming MESSAGE request; 

c) the To header fields set to the same value as the To header field that was received in the incoming MESSAGE 
request; 

d) the P-Charging-Vector header that includes: 

1) the value of the icid parameter if available; and 

2) the value of the orig-ioi parameter if available; 

e) the P-Charging-Function-Addresses header containing the values received in the incoming MESSAGE request 
or, if the P-Charging-Function- Addresses header was not received in the incoming MESSAGE request, indicate the 
values applicable for the list server in the P-Charging-Function- Addresses header; and 

f) the P-Asserted Identity header and Privacy header containing the values received in the MESSAGE request; 
The handling of the 200 (OK) response shall be in accordance with 3GPP TS 24.229 [5]. 

5.3.3.2 List server terminating case 

Upon receipt of a MESSAGE request that includes a PSI in the request URI the list server shall: 

1) check if the PSI is allocated to a predefined URI list and rejects the request in accordance with RFC 3261 [7] if 
it is not allocated. The following actions in this subclause shall only be performed if the distribution list URI is 
allocated; 

2) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; 
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3) create a 202 (Accepted) response. The response shall be in accordance with the procedures of 

3GPP TS 24.229 [5] subclause 5.7.1.2 in relation to the contents of the P-Charging-Function-Addresses header 
and the P-Charging-Vector header; and : 

a) include the P-Charging-Vector header including: 

i) the value of the icid parameter as received in the MESSAGE request; 

ii) the value of the orig-ioi parameter as received in the MESSAGE request; and 

iii) the term-ioi parameter, indicating the network of the list server; and 

b) include the P-Charging-Function- Addresses header as received in the MESSAGE request or, if the P- 
Charging-Function-Addresses header was not received in the MESSAGE request, indicate the values 
applicable for the list server in the P-Charging-Function- Addresses header; and 

4) send the 202 (Accepted) response. 

5.3.3.3 List Server processing the MESSAGE URI-llst 

Upon receiving the MESSAGE request with the URI-list included in the multipart body, the List Server shall inform the 
UE that it has received the MESSAGE request by returning the 202 (Accepted) response. Subsequently, the List Server 
shall create a MESSAGE request for each intended recipient listed in the URI-list, and it shall insert the immediate 
message payload into the body of each outgoing MESSAGES request. 

When creating the outgoing MESSAGE requests destined for each recipient, the List Server shall follow the procedures 
described in the 3GPP TS 24.229 [5]. The List Server shall populate the header fields of each outgoing MESSAGE 
request as follows: 

the Request-URI set to the SIP URI of the intended recipient; 

the From header field set to the same value as the From header field that was received in the incoming 
MESSAGE request; 

the To header set to the SIP URI of the intended recipient; and 

the remaining headers set to the values as specified in 3GPP TS 24.229 [5] subclause 5.7.3. 

The List Server shall also compose the multipart body of the outgoing MESSAGE request as specified in the 
RFC 5365 [12], and included it in the outgoing MESSAGE request. 

When sending the MESSAGE request to each recipient, and processing the respective responses, the List Server shall 
behave as specified in the 3GPP TS 24.229 [5] subclause 5.7. 

5.3.3.4 List server support of MESSAGE URI-lists 

A list server shall support the relay requirements of RFC 5360 [16]. The list server may also support the store and 
forward server requirements of RFC 5360 [16]. 



6 Protocol using SIP for session-mode messaging 

6.1 Introduction 

6.2 Functional entities 



6.2.1 User Equipment (UE) 



For the purpose of session-mode messaging, the UE shall implement the role of a Participant as described in 
subclause 6.3.1. 
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6.3 Role 

6.3.1 Participant 

6.3.1.1 General 

The participant shall perform SIP related session procedures in accordance with 3GPP TS 24.229 [5] to set up the 
dialog used for session-based messaging. 

6.3.1 .2 Session initiation - mobile originating case 

When the originating participant wishes to engage the terminating participant in a session-mode message session, it 
shall use the call initiation procedure specified in 3GPP TS 24.229 [5]. The Request URI header shall include the URI 
of the terminating participant. 

6.3.1 .3 Session initiation - mobile terminating case 

When the terminating participant receives an initial INVITE request from the originating endpoint proposing a message 
session, the terminating participant shall apply the procedures as specified in 3GPP TS 24.229 [5]. 

6.3.2 Intermediate Node 

6.3.2.1 General 

The intermediate node shall act as a Routeing B2BUA as specified in subclause 5.7 in 3GPP TS 24.229 [5]. 

6.3.2.2 Generic procedures for all methods at the intermediate node 

6.3.2.2.1 Intermediate node - originating case 

The intermediate node shall follow the procedures of 3GPP TS 24.229 [5] subclause 5.7.3 when acting as an originating 
UA. 

6.3.2.2.2 Intermediate node - terminating case 

Upon receipt of an initial request the intermediate node shall follow the procedures of 3GPP TS 24.229 [5] 
subclause 5.7.1.2 in relation to the contents of the P-Charging-Function-Addresses header and the P-Charging-Vector 
header. 

When creating the first response for this initial request, the intermediate node shall: 

1) include the P-Charging- Vector header including: 

a) the value of the icid parameter as received in the initial request; and 

b) the value of the orig-ioi parameter as received in the initial request; and 

c) the term-ioi parameter, indicating the network of the intermediate node; and 

2) include the P-Charging-Function- Addresses header as received in the initial request or, if the P-Charging- 
Function- Addresses header was not received in the initial request indicate the values applicable for the 
conference in the P-Charging-Function- Addresses header. 

When creating responses for an initial INVITE request, the intermediate node shall additionally send the 200 (OK) 
response to the initial INVITE request only after the resource reservation has been completed. 
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6.3.2.3 Session Initiation 

6.3.2.3.1 Session initiation - originating case 

The intermediate node shall follow the procedures of 3GPP TS 24.229 [5] at call initiation. 

The intermediate node shall populate the INVITE as specified for a Routeing B2BUA with the following clarification: 

a) the Request URI to the URI as in the received Request URI: 

b) the To header to the same display name and URI as in the received To header; 

c) the From header sent includes the same display name and URI as in the From header in the received INVITE; 
and 

d) the P-Asserted-Identity header and privacy includes the same information as in the received P-Asserted-Identity 
header and Privacy header; and 

If the intermediate node is not able to establish a TCP connection for the MSRP session the intermediate node shall 
send BYE towards the participant and release the associated recourses. 

6.3.2.3.2 Session initiation - terminating case 

Upon receipt of an INVITE request that includes an the terminating participant URI in the request URI, the intermediate 
node shall: 

1) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; and 

2) establish the session in accordance with 3GPP TS 24.229 [5]. 

3) create a 200 (OK) response. 

7 Protocol using SIP for session-mode messaging 

conferences 

7.1 Introduction 

Void. 

7.2 Functional entities 

7.2.1 User Equipment (UE) 

For the purpose of session-mode messaging conferences, the UE shall implement the role of a Participant as described 
in subclause 6.3.1 and the the procedures described in subclause 5.2.1 in 3GPP TS 24.147 [10]. 

7.2.2 Media Resource Function Controller (MRFC) 

For the purpose of session-based messaging conferences, the MRFC shall follow the procedures described in 
subclause 5.2.2 in 3GPP TS 24.147 [10]. 

7.2.3 Conferencing Application Server (AS) 

For the purpose of session-based messaging conferences, the AS shall follow the procedures described in 
subclause 5.2.3 in 3GPP TS 24.147 [10]. 
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8 Protocol using SDP for session-mode messaging 

and session-mode messaging conferences 

8.1 Introduction 

8.2 Functional entities 

8.2.1 User Equipment (UE) 

For the purpose of session-mode messaging and session-mode messaging conferences, the UE shall implement the role 
of: 

an SDP offerer as described in subclause 8.3.1; and 

an SDP answerer as described in subclause 8.3.2. 

8.2.2 Media Resource Function Controller (MRFC) 

The MRFC shall implement the role of an intermediate node as described in subclause 8.3.3. 

8.2.3 Application Server (AS) 

The AS shall implement the role of an SDP offerer, as described in subclause 8.3. 1, and an SDP answerer, as described 
in subclause 8.3.2 when engaged in a session mode session between a SDP offerer and SDP answerer. 

NOTE: An AS, that is on the signalling path for the related SIP signalling, is not mandated to terminate the 
related MSRP. 

8.3 Role 
8.3.1 SDP offerer 

When an SDP offerer wants to create a session mode massaging session, the SDP offerer shall populate the SDP as 
specified in subclause 6.1 in 3GPP TS 24.229 [5]. SDP offerer shall also include: 

a) a media attribute in accordance with RFC 4975 [9]; 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with 
RFC 4975 [9]; 

c) the address of the SDP offerer in the path attribute, in accordance with RFC 4975 [9]; and 

d) an a=setup attribute in accordance with RFC 6135 [18]. 

The SDP may also include an a=max-size attribute. The attribute shall be formatted in accordance with RFC 4975 [9] 

The SDP offerer may want to indicate to the other user(s), that the SDP offerer is prepared to receive isComposing 
information, then it shall add the MIME type 'application/ im-iscomposing-nxml to the accept type or access-wrapped 
types attributes. 

At the receipt of the SDP answer, if the SDP answer contains an a=setup attribute with a "passive" value, the SDP 
offerer shall set up a TCP connection (if not already available) when an IP -CAN bearer with sufficient QoS is available. 

In accordance with RFC 6135 [18], the SDP offerer shall not include an a=connection attribute in the initial SDP offer. 
For file transfer, the SDP shall also include media level attributes in accordance with RFC 5547 [15], with the exception 
that it shall include the file selector attribute (a=file-selector) with at least a size parameter. 
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When the 200 (OK) response for the last MSRP SENT is received, the SDP offerer shall close the MSRP media 
stream(s) for that particular file transfer, by sending an SDP offer where the m line port value for the file transfer media 
stream is set to zero, unless the MSRP media stream is the only stream in the SIP session, in which case a SIP BYE 
request shall be sent in order to terminate the SIP session. 

8.3.2 SDP answerer 

When receiving an SDP offer the SDP answerer shall populate the SDP answer as specified in subclause 6. 1 in 
3GPP TS 24.229 [5]. In addition the answerer shall include: 

a) a media attribute in accordance with the received media attribute in the SDP offer; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with 
RFC 4975 [9]; 

c) the MSRP URI of the SDP answerer in the path attribute in accordance with RFC 4975 [9]; and 

d) an a=setup attribute in accordance with RFC 6135 [18]. 

The SDP answerer may also include an a=max-size attribute. The attribute shall be formatted in accordance with 
RFC 4975 [9]. 

If SDP answerer receives the MIME type 'application/im-iscomposing+xml' in the accept-types or accept-wrapped- 
types attribute and the SDP answerer accepts the exchange of isComposing information the SDP answerer shall add the 
MIME type 'application/im-iscomposing-nxml' to the accept-types or access-wrapped types attributes. 

If the SDP answer contains an a=setup attribute with an "active" value, the SDP answerer shall set up a TCP connection 
(if not already available) when an IP-CAN bearer with sufficient QoS is available. 

For file transfer, the answerer shall behave in accordance with RFC 5547 [15]. 

8.3.3 Intermediate node 

8.3.3.1 Intermediate node Originating case 

8.3.3.1 .1 Sending of an SDP offer 

The intermediate node shall create an SDP offer, which shall include: 

a) a media attribute in accordance with the media attribute received in the received in the SDP offer.; 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes as provisioned in the 
intermediate node. The attribute shall be formatted in accordance with RFC 4975 [9]; 

c) a MSRP URI of the Intermediate node in the path attribute to be used when the SDP answerer wants to send a 
MSRP message to the conference. The attribute shall be formatted in accordance with RFC 4975 [9]; 

d) the MIME type 'application/ im-iscomposing-nxml to the accept type or access-wrapped types attributes if it is 
received from the SDP answerer; and 

e) an a=setup attribute in accordance with RFC 6135 [18]. 

The SDP may also include an a=max-size attribute. The attribute shall be formatted in accordance with RFC 4975 [9]. 

At the receipt of the SDP answer, if the SDP answer contains an a=setup attribute with a "passive" value the, 
intermediate node shall set up a TCP connection (if not already available) when an IP-CAN bearer with sufficient QoS 
is available. 

In accordance with RFC 6135 [18], the intermediate node shall not include an a=connection attribute in an SDP offer or 
answer. 

For file transfer, the SDP shall also include media level attributes in accordance with RFC 5547 [15], with the exception 
that it shall include the file selector attribute (a=file-selector) with at least a size parameter. 
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8.3.3.2 Intermediate node Terminating case 

8.3.3.2.1 Sending of a SDP answer 

The intermediate node shall at the receipt of a SDP offer create a SDP answer. The SDP answer shall include: 

a) a media attribute in accordance with the received media attribute in the SDP offer; 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with 
RFC 4975 [9]; 

c) a MSRP URI in the path attribute to be used when the SDP answerer shall send a MSRP message to the 
conference. The attribute shall be formatted in accordance with RFC 4975 [9]; 

d) the MIME type 'application/ im-iscomposing+xml to the accept type or access-wrapped types attributes if it is 
received from the SDP offerer; and 

e) an a=setup attribute in accordance with RFC 6135 [18]. 

If the SDP answer contains an a=setup attribute with an "active" value the, SDP intermediate node shall set up a TCP 
connection (if not already available) when an IP-CAN bearer with sufficient QoS is available. 

The SDP may also include an a=max-size attribute. The attribute shall be formatted in accordance with RFC 4975 [9]. 

9 Protocol using MSRP for session-mode messaging 

and session-mode messaging conferences 

9.1 Introduction 

9.2 Functional entities 

9.2.1 User Equipment (UE) 
9.2.1.1 General 

The UE shall: 

implement the role of an MSRP sender as described in subclause 9.3. 1; and 
implement the role of an MSRP receiver as described in subclause 9.3.2. 

9.2.2 Application Server (AS) 

The AS shall implement the role of a MSRP sender, as described in subclause 9.3.1, and a MSRP receiver, as described 
in subclause 9.3.2 when engaged in a session mode session between a MSRP sender and MSRP receiver. 

NOTE: An AS, that is on the signalling path for the related SIP signalling, is not mandated to terminate the 
related MSRP. 

9.2.3 Media Resource Function Processor (MRFP) 

The MRFP shall implement the role of an intermediate node as described in subclause 9.3.3. 
The MRFP may implement the role of an MSRP sender as described in subclause 9.3.1. 
The MRFP may implement the role of an MSRP receiver as described in subclause 9.3.2. 
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9.3 Role 

9.3.1 MSRP sender 

9.3.1.1 MSRP sender sends a message 

When a MSRP sender wishes to send a message, the MSRP sender shall ensure that the message length is not longer 
than the a=max-size attribute, as received in a SDP offer or a SDP answer. Depending on the message length the 
message may be included in one SEND request or chunked into a number of SEND requests. The MSRP sender shall 
follow the procedures and rules as specified in RFC 4975 [9], when the MSRP sender fragments a message into a 
number SEND requests. 

The SEND request shall include the Byte-Range header. The MSRP sender shall populate the Byte-Range header fields 
as follows: 

the range end set to * (interruptible), to make the chunks interruptible, if the SEND request is longer than 2048 
octets; and 

the total field set to the total size of the message. 

The MSRP sender shall create a SEND request in accordance with RFC 4975 [9] and RFC 6135 [18], where the value 
of To-Path is the MSRP URI shall be set to value of path attribute received in a SDP offer or a SDP answer. 

If it is possible to exchange isComposing information, the MSRP sender may include in a SEND request an 
isComposing status message as defined in RFC 3994 [13]. 

9.3.2 MSRP receiver 

When a MSRP receiver receives a SEND request, the MSRP receiver shall parse the SEND request. The MSRP 
receiver shall either send a response including: 

a) a 200 (OK) status-code , as specified in RFC 4975 [9], for the concerned SEND message if the parsing was 
successful; or 

b) an appropriate status-code, as specified in RFC 4975 [9], for the concerned SEND message if the parsing was 
unsuccessful. 

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) 
belonging to the message. It shall either be: 

a) a successful REPORT request including status-code 200 (OK) if a complete message is received and the Report- 
Success header in the SEND request was set to "yes"; or 

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in RFC 4975 [9] if the 
MSRP receiver can conclude that a complete message is not received and the Report-Failure header is set to 
"yes" or not included. The criteria to conclude that a complete message is not received are specified in 

RFC 4975 [9]. 

9.3.3 Intermediate node 

9.3.3.1 Intermediate node terminating case 

When an intermediate node receives a SEND request, the intermediate node shall: 
1) parse the SEND request and either send a response including: 

a) a 200 (OK) status-code, as specified in RFC 4975 [9], for the concerned SEND message, if the parsing was 
successful; or 

b) an appropriate status-code, as specified in RFC 4975 [9], for the concerned SEND message if the parsing was 
unsuccessful.; and 
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2) determine that a complete message has been received. The following actions in this subclause shall only be 
performed if a complete message is received. 

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) 
associated to the same message. It shall either be: 

a) a successful REPORT request including status-code 200 (OK) if the intermediate node concludes that all 
available users on the distribution list has received the complete message or a concerned user has received the 
complete message and the Report-Success header in the SEND request was set to "yes"; or 

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in RFC 4975 [9] if the 
intermediate node conclude that a complete message has not been received or that a complete message has not 
been able to be delivered to all available users on the distribution list or to a particular member of the 
distribution list. 

9.3.3.2 Intermediate node originating case 

When an intermediate node wishes to send a message, the intermediate shall ensure that the message length is not 
longer than the a=max-size attribute, as received in a SDP offer or a SDP answer. Depending on the message length the 
message may be included in one SEND request or chunked into a number of SEND requests. The intermediate node 
shall follow the procedures and rules as specified in RFC 4975 [9], when the intermediate node fragments a message 
into a number SEND requests. 

The SEND request shall include the Byte-Range header. The MSRP sender shall populate the Byte-Range header fields 
as follows: 

the range-end field set to * (interruptible), to make the chunks interruptible, if the SEND request is longer than 
2048 octets; and 

the total field set to the total size of the message. 

The intermediate shall create a SEND request in accordance with RFC 4975 [9] and RFC 6135 [18] with the following 
clarifications: 

1) set the Report-Success header as received in the SEND request; 

2) set the Report-Failure header as received in the SEND request; and 

3) depending on the received MSRP URI 

a) either send the SEND request to all available user of the conference; or 

b) send the SEND request to one MSRP receiver. 
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Annex A (informative): 

Example signalling flows of messaging service operation 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for conferencing within the IP Multimedia CN Subsystem (IMS) based 
on the Session Initiation Protocol (SIP), SIP Events, the Session Description Protocol (SDP) and other protocols. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.228 [6]. 

A.2 Introduction 

A.2.1 General 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [4] subclause 4. 1 applies with the additions specified 
below. 

In order to differentiate between messages for SIP and MSRP, the following notation is used: 

INVITE 



-► SIP message 

inspo 
(in bold style) 



^^^ fc^ Reliable transport protocol messages 



SEND 

^^^^^^ MRSP message (in bold style) 



Figure A.2.2-1 : Signalling flow notation 



A. 3 Signalling flows demonstrating immediate messaging 

The signalling flow for immediate messaging is shown in subclause 10.6 of 3GPP TS 24.228 [4]. 

A. 4 Signalling flows demonstrating session-based 
messaging 

A.4.1 Introduction 

This subclause provides signalling flows for session-based messaging, established both with and without preconditions. 
How the signalling flow for session-based messaging looks like depends on the following: 

a) at what point in time the IP-CAN for the media component (MSRP) is set up; or 

b) whether preconditions and reliable provisional responses are used or not. 
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A.4.2 Establishing a session for session-based messaging 
without preconditions 

Figure A.4.2- 1 shows the establishment of an MSRP session between two users without the usage of preconditions and 
reUable provisional responses as well as the first message being sent over the established connection. 

It is assumed that both the originating UE and terminating UE are using an IP-CAN with a separate bearer for SIP 
signalling which means that each UE needs to reserve a new IP -CAN bearer for the message session media component 
prior to sending the first MSRP message. 
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UE#1 Home Network 



UE#2 Home Network 



UE#2 Visited Network 



UE#1 



P-CSCF#1 



—1. INVITE ► 

-2. 100 Trying - 



-22. 200 OK — 
— 23.ACK M 



28. Reserve IP- 
CAN bearer for 
media 



S-CSCF#1 



-3. INVITE- 



-4. 1 00 Trying - 



l-CSCF#2 



5. Evaluation of Initial 
Filter Criteria 



-21.200OK- 



-24. ACK- 



-e.lNVITE ► 



-7. lOOTrying- 



S-CSCF#2 



8. HSS query 



-20.200OK- 



— 9. INVITE — 
-10. 100 Trying — 



P-CSCF#2 



11. Evaluation of 
Initial Filter Criteria 



-1 9.200 OK- 



-25. ACK- 



.29.TCPsetupi 



■30.SEND- 

I 
■ 31.200 OK" 



-12. INVITE - 



-13. 100 Trying 



-18.200OK- 



-26.ACK- 



UE#2 



-14. INVITE - 



-15. lOO.Trying- 



ie.Reserve IP-CAN 
bearer for media 



-17. 200OK- 



-27.ACK > 



Figure A.4.2-1 : Establishment of MSRP session 
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The details of the signalling flows are as follows: 

1. INVITE request (UE#1 to P-CSCF#1) - see example in table A.4.2-1 

The originating UE wants to initiate a session-based message session with the terminating UE. The 
originating UE creates a local MSRP URL, which can be used for the communication between the two user 
agents. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the 
MSRP communication. 

Table A.4.2-1 : INVITE request (UE#1 to P-CSCF#1) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : user2_publicl@home2 . net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642 ; port-s=7531 
Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 2855 TCP/MSRP* 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 2855/slll271; tcp 

a=max-size : 1310 72 

a=msrp-cema 

a=setup : active 



SDP The SDP contains a set of content types supported by UE#1 and desired by the user at UE#1 for 

this session in the accept-types attribute and indicates the maximum size message that can be 
received by UE#1 in the max-size attribute. 



2. 100 (Trying) response (P-CSCF#1 to UE#1) - see example in table A.4.2-2 

The P-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-2: 100 (Trying) response (P-CSCF#1 to UE#1) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



3. INVITE request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.2-3 

The INVITE request is forwarded to the S-CSCF. 
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Table A.4.2-3: INVITE request (P-CSCF#1 to S-CSCF#1) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : G9 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip ipcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



4. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) - see example in table A,4.2-4 

The S-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-4: 100 (Trying) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP pcsc 


f 1 .visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555 


: : aaa :bbb : ccc 


:ddd] 


:1357; 


comp= 


=sigcomp 


;branch=z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 
Content - 


Length: 



















5. Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. 

6. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table A.41-6 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2. 
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Table A.4.2-6: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
a= 

a= 



7. 100 (Trying) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.2-7 

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.2-7: 100 (Trying) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP scscf 1. homel 
pcscf 1 .visitedl .net ;branch= 


net;branch=z9hG4bK332b23.1, SIP/2 
=z9hG4bK240f34.1, SIP/2. 0/UDP 


0/UDP 


[5555: : 


aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 

Content-Le 


ngth : 













8. Cx: User Location Query procedure 

The 1-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

9. INVITE request (I-CSCF#2 to S-CSCF#2) - see example in table A.4.2-9 

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination. 
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Table A.4.2-9: INVITE request (l-CSCF#2 to S-CSCF#2) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 
scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 67 

Route : <sip : scscf 2 . home2 . net ; lr> 

Record-Route : 

P-Asserted- Identity : 

P-Charging-Vector : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 



10. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.2-10 

S-CSCF#2 responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-10: 100 (Trying) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP icscf2_s. 
scscf 1 .homel .net /branch 


home2 . net ; branch= 
=z9hG4bK332b23.1, 


z9hG4bK871yl2.1, 
SIP/2. 0/UDP 


SIP/2. 


0/UDP 


pcscf 1 
[5555: 


visitedl .net ;branch=z 
aaa:bbb:ccc:ddd] :1357 


3hG4bK240f34.1, SIP/2. 0/UDP 
-comp=sigcomp;branch=z9hG4bKnashds7 




From: 
















To: 
















Call-ID: 
















CSeq: 
Content-Length: 















1 1 . Evaluation of initial filter criteria 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. 

12. INVITE request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.2-12 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 
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Table A.4.2-12: INVITE request (S-CSCF#2 to P-CSCF#2) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87.1, SIP/2. 0/UDP 
icscf 2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 66 

Route : <sip : pcscf 2 . visited2 .net; lr> 

Record-Route : <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 
<sip : pcscf 1 .visitedl .net; lr> 

P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Allow: 

Accept : 

P- Called- Party- ID : <sip :user2_publicl@home2 .net> 

Content-Type : 

Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 



13. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.2-13 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.2-13: 100 (Trying) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK764z 


87.1, SIP/2 


0/UDP 


icscf2_ 
scscf 1 


_s .home2 .net ;branch=z9hG4bK871yl2 . 1 
homel. net ;branch=z9hG4bK332b23.1, 


, SIP/2. 0/UDP 
SIP/2. 0/UDP 




pcscf 1 
[5555: 


visitedl. net ;branch=z9hG4bK240f 34. 
aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp 


1, SIP/2 
;branch= 


.0/UDP 
z9hG4bKnashds7 


From: 












To: 












Call-ID: 












CSeq: 
Content-Length: 











14. INVITE request (P-CSCF#2 to UE#2) - see example in table A.4.2-14 

P-CSCF#2 forwards the INVITE request to the terminating UE. 
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Table A.4.2-14: INVITE request (P-CSCF#2 to UE#2) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 
Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 

P-Called-Party-ID: 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 



15. 100 (Trying) response (UE#2 to P-CSCF#2) - see example in table A,4.2-15 

The terminating UE sends a 100 (Trying) response provisional response to P-CSCF#2. 

Table A.4.2-15: 100 (Trying) response (UE#2 to P-CSCF#2) 



SIP/2.0 100 Trying 




Via: SIP/2 . 0/UDP pcscf 2 .visited2 .net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1, 


SIP/2. 0/UDP 


scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2. 0/UDP 




icscf2 s.home2.net;branch=z9hG4bK871yl2.1, SIP/2. 0/UDP 




scscfl. homel. net ;branch=z9hG4bK332b23.1, SIP/2. 0/UDP 




pcscf 1. visitedl. net;branch=z9hG4bK240f 34.1, SIP/2. 0/UDP 




[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





16. Reserve IP-CAN bearer for media 

The terminating UE accepts the message session. The terminating UE reserves an IP-CAN bearer for the 
message session media component. 

17. 200 (OK) response (UE#2 to P-CSCF#2) - see example in table A.4.2-17 

After reserving an IP-C/VN bearer for the message session media component the terminating UE sends a 200 
(OK) response for the INVITE request containing SDP that indicates that the terminating UE has accepted 
the message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP 
SETUP from the originating UE. 
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Table A.4.2-17: 200 (OK) response (UE#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb:ccc:ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 . visitedl .net ; lr> 
Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <sip :userl_publicl@homel .net>; tag=171828 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 
Supported: gruu 
Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=message 2855 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp:// [5555 : : eee : f f f : aaa : bbb] : 2855/s234167; tcp 

a=max-size : 65536 

a=msrp-cema 

a=setup :passive 



SDP The SDP contains the set of offered content types supported by UE#2 and desired by the user at 

UE#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be received by UE#2 in the max-size attribute. 



18. 200 (OK) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.2-18 

P-CSCF#2 forwards the 200 (OK) response to S-CSCF#2. 
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Table A.4.2-18: 200 (OK) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted-Identity : John Smith" <sip :user2_publicl@home2 .net> 

Privacy: 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 

P-Access-Network-Inf o : 

From: 

To: 

Call-ID: 

CSeq: 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



19. 200 (OK) response (S-CSCF#2 to I-CSCF#2) - see example in table A,4.2-19 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 
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Table A.4.2-19: 200 (OK) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 .net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 
Privacy: 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term- ioi=home2 . net 
P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a5 5:b44:c33:d22]; 

ecf= [5555: : If f : 2ee : 3dd : 4cc] ; ecf= [5555 : : 6aa : 7bb : Bcc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 



20. 200 (OK) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.2-20 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table A.4.2-20: 200 (OK) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf l.homel.net ;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : :aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
Privacy: none 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



21. 200 (OK) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.2-21 

S-CSCF#1 forwards the 200 (OK) response to P-CSCF#1. 



£75/ 



3GPP TS 24.247 version 1 0.4.0 Release 1 31 ETSI TS 1 24 247 V1 0.4.0 (201 2-1 0) 

Table A.4.2-21 : 200 (OK) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
Privacy: 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 

a= 



22. 200 (OK) response (P-CSCF#1 to UE#1) - see example in table A.4.2-22 

P-CSCF#1 forwards the 200 (OK) response to the originating UE. 

Table A.4.2-22: 200 (OK) response (P-CSCF#1 to UE#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip :pcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net : 7531; lr;comp=sigcomp> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 



23. ACK request (UE#1 to P-CSCF#1) - see example in table A.4.2-23 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 
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Table A.4.2-23: ACK request (UE#1 to P-CSCF#1) 



ACK sip: userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Route : <sip :pcscf 1 . visitedl .net : 7531; Ir ; comp=sigcomp> , <sip:scscfl .homel .net; lr>, 

<sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 
From: <sip :userl_publicl@homel .net>; tag=17182 8 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 ACK 
Content-Length: 



24. ACK request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.2-24 

The P-CSCF#1 forwards the ACK request to S-CSCF#1. 

Table A.4.2-24: ACK request (P-CSCF#1 to S-CSCF#1) 



ACK sip: userl publiciohomel 


net 


;gr= 


arn : uuid 


f81d4fae-7dec- 


lldO-a765-OOaOc91eSbfS 




;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP pcscfl. visitedl 


.net 


;branch=z9hG4bK240f 34 . 1 


, SIP/2 


0/UDP 






[5555: :aaa:bbb:ccc :ddd] :1357;comp 


= si 


gcomp , 


branch= 


=z9hG4bKnashds7 








Max- Forwards : 69 






















P-Access-Network-Info : 






















Route: <sip : scscfl .homel .net 


•lr> 


<s 


ip: 


scscf : 


.home 2 


net; lr> 


, <sip:pcscf2 


visited2 


net; lr> 


From: 






















To: 






















Call-ID: 






















Cseq: 

Content-Length: 























25. ACK request (S-CSCF#1 to S-CSCF#2) - see example in table A.4.2-25 

The S-CSCF#1 forwards the ACK request to the S-CSCF#2. 

Table A.4.2-25: ACK request (S-CSCF#1 to S-CSCF#2) 



ACK sip: userl publiciohomel. 


net ; gr=urn : uuid : 


f81d4fae-7dec 


-lldO 


-a765-00a0c91e6bf6 


;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP scscfl. homel 


. net ; branch=z9hG4bK332b23 . 1 , 


3IP/2 


0/UDP 






pcscfl .visitedl .net ; branch 


=z9hG4bK240f34.1 


, SIP/2. 0/UDP 










[5555: : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp; 
Max-Forwards: 68 


branch=z9hG4bKnashds7 






Route: <sip : scscf 2 .home2 .net ; 


lr>, <sip:pcscf2 


. visited2 .net 


;lr> 








From: 














To: 














Call-ID: 














Cseq: 

Content-Length: 















26. ACK request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.2-26 

S-CSCF#1 forwards the ACK request to P-CSCF#2. 
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Table A.4.2-26: ACK request (S-CSCF#2 to P-CSCF#2) 



ACK sip: [5555: : eee 


: f f f : aaa 


:bbb] : 88 05;comp= 


sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2 


0/UDP 


scscf 1 . homel . net 


;branch= 


z9hG4bK332b23.1, 


SIP/2. 0/UDP 




pcscf 1 . visitedl . 


net;branch=z9hG4bK240f34 


. 1, SIP/2. 0/UDP 




[5555: :aaa:bbb:ccc:ddd] : 


13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 


Max- Forwards : 67 










Route: <sip:pcscf2. 


visited2 


.net; lr> 






From: 










To: 










Call-ID: 










Cseq: 










Content-Length: 











27. ACK request (P-CSCF#2 to UE#2) - see example in table A.4.2.27 

P-CSCF#2 forwards the ACK request to the terminating UE. 

Table A.4.2-27: ACK request (P-CSCF#2 to UE#2) 



ACK sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max-Forwards: 66 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



28. Reserve IP-CAN bearer for media 

The originating UE reserves an IP-C/VN bearer for the message session media component. 

29. TCP setup 

The originating UE establishes a TCP connection using the IP-C/VN bearers established in step 16 and step 
28 to the host address and the port as specified in the MSRP URL received in the SDP Answer from the 
terminating UE. 

30. MSRP SEND request (UE#1 to UE#2) - see example in table A.4.2-30 

The originating UE sends the first message over the MSRP session with an MSRP SEND request using the 
established TCP connection. 

Table A.4.2-30: MSRP SEND request (UE#1 to UE#2) 



MSRP d93kswow SEND 




To-path:msrp:// [5555: : eee : f f f : aaa :bbb] : 3 3 33/s23416 7 ; tcp 




From-path:msrp:// [5555: : aaa :bbb : ccc : ddd] : 2855/slll271; tcp 




Message-ID: 8822 




Byte-Range: 1-77/77 




Content-Type: "text/plain" 




those are my principles. If you don't like them I have others 


- Groucho Marx . 


d93kswow$ 





To-path: The sender" s remote path 

From-path: The sender" s local URL 

Message-ID: A unique message ID for MSRP message. 
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Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

31. MSRP 200 (OK) response (UE#2 to UE#1) - see example in table A.4.2-31 

The terminating UE acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response 
using the established TCP connection. 

Table A.4.2-31 : MSRP 200 (OK) response (UE#2 to UE#1) 



MSRP d93kswow 200 OK 

To-path:msrp:// [5555: : aaa : bbb : ccc : ddd] : 2855/slll271 ; tcp 

From-path:msrp:// [5555: : eee : f f f : aaa :bbb] :3333/s234167; tcp 

d93kswow$ 



A.4.3 Establishing a session for session-based messaging with 
Intermediate Nodes 

Figure A.4.3- 1 shows the establishment of a MSRP session between two users with intermediate nodes being added to 
the signalling path as well as the first message being sent over the established connection. 

It is assumed that both the originating UE and terminating UE are using an IP -CAN with a separate bearer for SIP 
signalling which means that each UE needs to reserve a new IP -CAN bearer for the message session media component. 

This example is simplified, the MRFC and MRFP functions are shown as combined with AS#1 and AS#2 in this 
example. 
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Figure A.4.3-1 : Establishment of MSRP session with Intermediate Nodes 

The details of the signalhng flows are as follows: 

1. INVITE request (UE#1 to P-CSCF#1) - see example in table A.4.3-1 

The originating UE#1 wants to initiate a session-based message session with the terminating UE#2. UE#1 
creates a local MSRP URL, which can be used for the communication between the two user agents. It builds 
a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP 
communication. 
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Table A.4.3-1 : INVITE request (UE#1 to P-CSCF#1) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : user2_publicl@home2 . net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 2855 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 2855/slll271; tcp 

a=max-size : 1310 72 

a=msrp-cema 

a=setup : active 



SDP The SDP contains the set of content types supported by UE#1 and desired by the user at UE#1 for 

this session in the accept-types attribute and indicates the maximum size message that can be 
received by UE#1 in the max-size attribute. 



2. 100 (Trying) response (P-CSCF#1 to UE#1) - see example in table A.4.3-2 

The P-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-2: 100 (Trying) response (P-CSCF#1 to UE#1) 



SIP/2.0 100 Trying 






Via: SIP/2. 0/UDP [5555: 


: aaa : bbb : ccc : ddd] 


: 1357;comp=sigcomp;branch=z9hG4bKnashds7 


From: 






To: 






Call-ID: 






CSeq: 






Content-Length: 







3. INVITE request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.3-3 

The INVITE request is forwarded to the S-CSCF. 
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Table A.4.3-3: INVITE request (P-CSCF#1 to S-CSCF#1) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : G9 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip ipcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



4. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.3-4 

The S-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-4: 100 (Trying) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP pcsc 


f 1 .visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555 


: : aaa :bbb : ccc 


:ddd] 


:1357; 


comp= 


=sigcomp 


;branch=z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 
Content - 


Length: 



















5. Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. For 
sip:userl_publicl@homel.net S-CSCF#1 has origination initial filter criteria with service points of interest 
of Method = INVITE request and SDP m= 'message' and 'msrp' protocol that informs the S-CSCF to route 
the INVITE request to the AS sip:asl. homel. net. 

6. INVITE request (S-CSCF#1 to AS#1) - see example in table A.4.3-6 

S-CSCF#1 forwards the INVITE request to the AS#1. 
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Table A.4.3-6: INVITE request (S-CSCF#1 to AS#1) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK344a65 . 1 , SIP/2 . 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Route : <sip : asl .homel .net; lr>, <sip : Cb03a0s09a2sdfglkj490333@scscf 1 .homel .net ; lr> 
Record- Route : <sip lorigOscscf 1 .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
P-Access-Network-Info : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
P- Charging- Function-Addresses : ccf = [5555: :b99:c88:d77:eS6] ; ccf=[5555: :a5 5:b44:c33:d22] ; 

ecf= [5 555: :lff :2ee:3dd:4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 



7. 100 (Trying) response (AS#1 to S-CSCF#1) - see example in table A.4.3-7 

AS#1 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.3-7: 100 (Trying) response (AS#1 to S-CSCF#1) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP scscf 1. homel 
pcscf 1 .visitedl .net ;branch= 


net ; branch= z 9hG4bK3 44a 
=z9hG4bK240f34.1, SIP/2 


65.1, SIP/2 
.0/UDP 


0/UDP 


[5555: : 


aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 

Content-Le 


ngth : 













AS#1 establishes a TCP connection using the IP -CAN bearers established in step 1 to the host address and 
port as specified in the MSRP URL received in the SDP Offer from the originating UE#1. 

8. INVITE request (AS#1 to S-CSCF#1) - see example in table A.4.3-8 

AS#1 sends a new INVITE request to the S-CSCF#1 with the session attribute containing a unique URL for 
the AS#1 to receive media on. 



£75/ 



3GPP TS 24.247 version 1 0.4.0 Release 1 40 ETSI TS 1 24 247 V1 0.4.0 (201 2-1 0) 

Table A.4.3-8: INVITE request (AS#1 to S-CSCF#1) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP asl . homel . net ;branch=z9hG4bK240f 34 . 1 

Max- Forwards : 70 

Record-Route : <sip : asl . homel . net ; lr> 

Route: <sip:cb03a0s09a2sdfglkj4 90333@scscf 1 .homel .net;lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=323551024" 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=234567 

To : <sip :user2_publicl@home2 . net> 

Call -ID: s09a233cbsdfglkj4903 03aO 

Cseq: 278 INVITE 

Supported: 

Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept : 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933620 2987933620 IN IP6 7777 : : eee : ddd : ccc : aaa 

s = - 

c = IN IP6 7777 : :eee :ddd:ccc :aaa 

t = 

m=message 3927 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [7777 : : eee : ddd: ccc : aaa] : 3 92 7/s222 3 71; tcp 

a=max-size : 65536 

a=msrp-cema 

a=setup : active 



Record-Route The AS#1 includes a Record-Route header containing its SIP URL 

SDP The SDP contains the set of offered content types allowed by the policy of network homel in the 

accept-types attribute and indicates the maximum size message that can be received by UE#1 and 
allowed by the policy of network homel in the max-size attribute. 



9. 100 (Trying) response (S-CSCF#1 to AS#1) - see example in table A.4.3-9 

S-CSCF#1 sends a 100 (Trying) response provisional response to AS#1. 

Table A.4.3-9: 100 (Trying) response (S-CSCF#1 to AS#1) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP asl . homel . net ;branch=z9hG4bK240f 34 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



10. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table A.4.3-10 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2. As the S-CSCF#1 does not know whether the I- 
CSCF at home2.net is a loose router or not, it does not introduce a Route header. 
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Table A.4.3-10: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

asl .homel .net ;branch=z9hG4bK240f 34 . 1 
Max- Forwards : 69 

Record-Route : <sip : scscf 1 . homel . net ; lr> , <sip : asl . homel . net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=323551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
a= 

a= 



1 1. 100 (Trying) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.3-11 

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.3-11: 100 (Trying) response (l-CSCF#1 to S-CSCF#1) 



SIP/2.0 100 Trying 




Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , 


SIP/2. 0/UDP 


asl. homel. net ;branch=z9hG4bK240f 34.1 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





12. Cx: User Location Query procedure 

The 1-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

13. INVITE request (I-CSCF#2 to S-CSCF#2) - see example in table A.4.3-13 

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination. 
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Table A.4.3-13: INVITE request (l-CSCF#2 to S-CSCF#2) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

asl .homel .net ;branch=z9hG4bK240f 34 . 1 
Max- Forwards : 68 

Route: <sip : scscf 2 .home2 .net ; lr>, <sip : asl .homel .net ; lr> 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

ra= 
a= 
a= 
a= 



NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalHng 
path once the session is established. 

14. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.3-14 

S-CSCF#2 responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-14: 100 (Trying) response (S-CSCF#2 to i-CSCF#2) 



SIP/2 . 100 Trying 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

asl .homel .net;branch=z9hG4bK240f34 . 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



15. Evaluation of initial filter criteria 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. For 
sip: user2 publicl@home2.net S-CSCF#2 has termination initial filter criteria with service points of interest 
of Method = INVITE request and SDP m = 'message' and 'msrp' protocol that informs the S-CSCF to route 
the INVITE request to the AS sip:as2. home2.net. 

16. INVITE request (S-CSCF#2 to AS#2) - see example in table A.4.3-16 

S-CSCF#2 forwards the INVITE request to AS#2 
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Table A.4.3-16: INVITE request (S-CSCF#2 to AS#2) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87.1, SIP/2. 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

asl .homel .net ;branch=z9hG4bK240f 34 . 1 
Max- Forwards : 67 

Route : <sip : as2 . home2 . net ; lr> , <sip : s09a233cbsdf glkj 490303a0@scscf 2 . home2 . net ; lr> 
Record-Route: <sip : scscf 2 .home2 .net ; lr>, <sip : scscfl .homel .net ; lr>, <sip : asl .homel .net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : 
P- Charging- Function-Addresses : ccf=[6666::b99:c88:d77:e66]; ccf=[6666::a5 5:b44:c33:d22]; 

ecf= [6666: : If f : 2ee : 3dd: 4ee] ; ecf= [6666: : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 



17. 100 (Trying) response (AS#2 to S-CSCF#2) - see example in table A.4.3-17 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-17: 100 (Trying) response (AS#2 to S-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 
scscfl. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 
asl .homel .net ;branch=z9hG4bK240f 34 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



18. INVITE request (AS#2 to S-CSCF#2) - see example in table A.4.3-18 

AS#2 sends a new INVITE request to the S-CSCF#2 with the session attribute containing a unique URL for 
the AS#2 to receive media on. 
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Table A.4.3-18: INVITE request (AS#2 to S-CSCF#2) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP as2 .home2 .net;branch=z9hG4bK348923 .1 

Max-Forwards: 70 

Route: <sip: S09a233cbsdfglkj4903 03a0®scscf2 .home2 .net;lr> 

Record-Route : <sip : as2 . home2 . net ; lr> 

P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=423551024" 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=7871654 

To : <sip :user2_publicl@home2 .net> 

Call -ID: Os09glkj4 903a2sdf33cb03a 

Cseq: 210 INVITE 

Supported: 

Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept : 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933630 2987933630 IN IP6 9999 : : ccc : aaa : bbb : ddd 

s = - 

c=IN IP6 9999 :: ccc : aaa: bbb: ddd 

t = 

m=message 3333 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [9999 : : ccc : aaa : bbb : ddd] : 3333/s317121; tcp 

a=max-size : 32 76 8 

a=msrp-cema 

a=setup : active 



Record-Route The AS#1 includes a Record-Route header containing its SIP URL 

SDP The SDP contains the set of offered content types allowed by the policy of network home2 in the 

accept-types attribute and indicates the maximum size message that can be received by UE#1 and 
allowed by the policy of network home2 in the max-size attribute. 



19. 100 (Trying) response (S-CSCF#2 to AS#2) - see example in table A.4.3-19 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-19: 100 (Trying) response (S-CSCF#2 to AS#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP as2 . home2 . net ;branch=z9hG4bK348923 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



20. INVITE request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.3-20 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 
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Table A.4.3-20: INVITE request (S-CSCF#2 to P-CSCF#2) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87.1, SIP/2 . 0/UDP 

as2 .home2 .net ;branch=z9hG4bK348923 . 1 
Max- Forwards : 69 

Route : <sip :pcscf 2 . visited2 .net; lr> 

Record-Route : <sip : scscf 2 . home2 . net ; lr> , <sip : as2 . home2 . net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 

P- Called- Party- ID : <sip :user2_publicl@home2 .net> 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



21. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.3-21 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-21 : 100 (Trying) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 100 Trying 




Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, 


SIP/2. 0/UDP 


as2 .home2 .net;branch=z9hG4bK348923 . 1 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





22. INVITE request (P-CSCF#2 to UE#2) - see example in table A.4.3-22 

P-CSCF#2 forwards the INVITE request to the terminating UE. 
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Table A.4.3-22: INVITE request (P-CSCF#2 to UE#2) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 

as2 .home2 .net ;branch=z9hG4bK348923 . 1 
Max- Forwards : 68 
Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip : as2 . home2 . net ; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 

P-Called-Party-ID: 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



23. 100 (Trying) response (UE#2 to P-CSCF#2) - see example in table A.4.3-23 

UE#2 sends a 100 (Trying) response provisional response to P-CSCF#2. 

Table A.4.3-23: 100 (Trying) response (UE#2 to P-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 

as2 .home2 .net ;branch=z9hG4bK348923 . 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



24. Reserve IP-CAN bearer for media 

The terminating UE#2 accepts the message session and. UE#2 reserves an IP-CAN bearer for the message 
session media component. 

25. 200 (OK) response (UE#2 to P-CSCF#2) - see example in table A.4.3-25 

After reserving an IP-CAN bearer for the message session media component, the terminating UE#2 sends a 
200 (OK) response for the INVITE request containing SDP that indicates that UE#2 has accepted the 
message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP 
SETUP from AS#2. 
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Table A.4.3-25: 200 (OK) response (UE#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net : 5088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 

as2 .home2 .net ;branch=z9hG4bK348923 . 1 
Record-Route: <sip :pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>, <sip : scscf 2 .home2 .net ; lr>, , 

<sip : as2 . home2 . net ; lr> 
Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <sip :userl_publicl®homel .net>tag=78 716 54 
To : <sip : user2_publicl@home2 . net> ; tag=999456 
Call -ID: Os09glkj4 903a2sdf33cb03a 
Cseq: 210 INVITE 
Supported: gruu 
Contact : <sip: user2_publicl®home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 29879336302987933630IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=message 2855 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp:// [5555: : eee : f f f : aaa : bbb] : 2855/s417121; tcp 

a=max-size : 65536 

a=msrp-cema 

a=setup :passive 



SDP The SDP contains the set of offered content types supported by UE#2 and desired by the user at 

UE#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be received by UE#2 in the max-size attribute. 



26. 200 (OK) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.3-26 

P-CSCF#2 forwards the 200 (OK) response to S-CSCF#2. 
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Table A.4.3-26: 200 (OK) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 

as2 .home2 .net ;branch=z9hG4bK348923 . 1 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip :user2_publicl@home2 .net> 
Privacy: 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=423551024" 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 

a= 



27. 200 (OK) response (S-CSCF#2 to AS#2) - see example in table A.4.3-27 

S-CSCF#2 forwards the 200 (OK) response to AS#2. 

Table A.4.3-27: 200 (OK) response (S-CSCF#2 to AS#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP as2 .home2 .net;branch=z9hG4bK348923 .1 

Record-Route : 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 

Privacy: 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=423551024" ; orig-ioi=homel .net; 

term- ioi=home2 . net 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 



28. ACK request (AS#2 to S-CSCF#2) - see example in table A.4.3-28 

AS#2 generates a new ACK request and sends it to S-CSCF#2. 
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Table A.4.3-28: ACK request (AS#2 to S-CSCF#2) 



ACK sip: user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP as2 .home2 .net;branch=z9hG4bK348923 .1 
Max-Forwards: 70 

Route : <sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 
From: <sip :userl_publicl@homel .net>; tag=78 716 54 
To: <sip:user2_publicl@home2 .net>; tag=2217770 
Call -ID: Os09glkj4903a2sdf33cb03a 
Cseq: 210 ACK 
Content-Length: 



29. ACK request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.3-29 

S-CSCF#1 forwards the ACK request to P-CSCF#2. 

Table A.4.3-29: ACK request (S-CSCF#2 to P-CSCF#2) 



ACK sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, 


SIP/2. 0/UDP 


as2.home2.net;branch=z9hG4bK348923 .1 




Max- Forwards : 69 




Route : <sip :pcscf 2 . visited2 .net; lr> 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





30. ACK request (P-CSCF#2 to UE#2) - see example in table A.4.3.30 

P-CSCF#2 forwards the ACK request to UE#2. 

Table A.4.3-30: ACK request (P-CSCF#2 to UE#2) 



ACK sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 




Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, 


SIP/2. 0/UDP 


scscf2 .home2 .net;branch=z9hG4bK764z87 .1, SIP/2 . 0/UDP 




as2.home2.net;branch=z9hG4bK348923.1 




Max- Forwards : 6 8 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





31. TCP setup 



AS#2 estabUshes a TCP connection using the IP -CAN bearers established in step 24 to the host address and 
port as specified in the MSRP URL received in the SDP Answer from UE#2. 



32. 200 (OK) response (AS#2 to S-CSCF#2) - see example in table A.4.3-32 

AS#2 generates a 200 (OK) response to S-CSCF#2. 
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Table A.4.3-32: 200 (OK) response (AS#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

asl .homel .net ;branch=z9hG4bK240f 34 . 1 
Record-Route: <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr>, <sip : as2 .home2 .net ; lr> 
P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 
Privacy: 

P- Charging- Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024" 
From: <sip :userl_publicl@homel .net>tag=234567 
To: <sip:user2_publicl@home2 .net>; tag=98 98 982 3 
Call -ID: s0 9a2 3 3cbsdfglkj4 90 3 3a0 
CSeq: 278 INVITE 
Supported: gruu 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933640 2987933640 IN IP6 9999 : : ccc : aaa : bbb : ddd 

s = - 

c = IN IP6 9999: :ccc:aaa:bbb:dddt = 

m=message 2855 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [9999 : :ccc : aaa : bbb : ddd] : 2855/s317122 ; tcp 

a=max-size : 32 76 8 

a=msrp-cema 

a=setup :passive 



SDP The SDP contains the set of answered content types supported by UE#2 in the accept-types 

attribute and indicates the maximum size message that can be received by UE#2 and allowed by 
the policy of network home2 in the max-size attribute. 



33. 200 (OK) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.3-33 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 
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Table A.4.3-33: 200 (OK) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 

scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

asl .homel .net ;branch=z9hG4bK240f 34 . 1 
Record-Route : 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 
Privacy: 
P-Charging-Vector : icid-value"AyretyU0dm+6O2IrT5tAFrbHLso=323551024" ; orig-ioi=homel .net; 

term- ioi=home2 . net 
P- Charging- Function-Addresses : ccf=[6666::b99:c88:d77:e66]; ccf=[6666::a5 5:b44:c33:d22]; 

ecf= [6666 : : If f : 2ee : 3dd: 4ee] ; ecf= [6666 : : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Supported 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



34. 200 (OK) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.3-34 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table A.4.3-34: 200 (OK) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf l.homel.net , -branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

asl .homel .net ;branch=z9hG4bK240f 34 . 1 
Record-Route : 
P-Asserted- Identity : 
Privacy: none 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 
a= 



35. 200 (OK) response (S-CSCF#1 to AS#1) - see example in table A.4.3-35 

S-CSCF#1 forwards the 200 (OK) response to AS#1. 
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Table A.4.3-35: 200 (OK) response (S-CSCF#1 to AS#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP asl . homel . net ;branch=z9hG4bK240f 34 . 1 

Record-Route : 

P-Asserted- Identity : 

Privacy: 

P-Charging-Vector : 

P- Charging- Function-Addresses : ccf=[5555::b9 9:c88:d77:e6 6]; ccf=[5555::a5 5:b44:c33:d22] 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 
a= 



36. ACK request (AS#1 to S-CSCF#1) - see example in table A.4.3-36 

AS#1 generates an ACK request and sends it to S-CSCF#1. 

Table A.4.3-36: ACK request (AS#1 to S-CSCF#1) 



ACK sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d9 9-ad76cc7f c74 SIP/2 . 

Via: SIP/2. 0/UDP asl. homel. net;branch=z9hG4bK240f 34 .1 

Max- Forwards : 70 

Route: <sip: scscfl .homel .net ; lr>, <sip : scscf 2 .home2 .net ; lr>, <sip : as2 .home2 .net ; lr> 

From: <sip :userl_publicl@homel .net>; tag=234567 

To: <sip:user2_publicl@home2 .net>; tag=98 98 982 3 

Call-ID: S09a23 3cbsdfglkj4 90 3 3a0 

Cseq: 278 ACK 

Content-Length: 



37. ACK request (S-CSCF#1 to S-CSCF#2) - see example in table A.4.3-37 

The S-CSCF#1 forwards the ACK request to S-CSCF#2. 

Table A.4.3-37: ACK request (S-CSCF#1 to S-CSCF#2) 



ACK sip: user2_publicl@home2 .net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad7Scc7fc74 SIP/2.0 
Via: SIP/2. 0/UDP scscfl. homel. net ;branch=z9hG4bK344a65.1, SIP/2. 0/UDP asl .homel .net ;branch= 

z9hG4bK240f34.1 
Max-Forwards: 69 

Route : <sip : scscf 2 . home2 . net ; lr> , <sip : as2 . home2 . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



38. ACK request (S-CSCF#2 to AS#2) - see example in table A.4.3-38 

The S-CSCF#2 forwards the ACK request to the AS#2. 
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Table A.4.3-38: ACK request (S-CSCF#2 to AS#2) 



ACK sip: user2_publicl@home2 .net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 SIP/2.0 
Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK344a65 .1, SIP/2 . 0/UDP 

asl .homel .net ;branch=z9hG4bK240f 34 . 1 
Max- Forwards : 68 
Route: <sip : as2 .home2 .net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



39. TCP setup 



AS#1 establishes a TCP connection to the host address and port as specified in the MSRP URL received in 
the SDP Answer from the AS#2. 



40. 200 (OK) response (AS#1 to S-CSCF#1) - see example in table A.4.3-40 

AS#1 generates a 200 (OK) response and sends it to S-CSCF#1. 

Table A.4.3-40: 200 (OK) response (AS#1 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl. homel. net;branch=z9hG4bK344a65.1, SIP/2 . 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : <sip : asl . homel . net ; lr> , <sip : scscfl . homel . net ; lr> , 

<sip : pcscf 1 .visitedl .net; lr> 
P-Asserted- Identity : 
Privacy: 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
From: <sip :userl_publicl®homel .net>; tag=17182 8 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 127 INVITE 
Supported 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 > 
Allow: 

Content-Type : 
Content-Length : 

v=0 

o=- 2987933642 2987933642 IN IP6 7777 :: eee : ddd : ccc : aaa 

s = - 

c = IN IP6 7777 : :eee :ddd:ccc :aaa 

t = 

m=message 3927 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [7777 : : eee : ddd: ccc : aaa] : 3 92 7/s222 3 72 ; tcp 

a=max-size : 32 76 8 

a=msrp-cema 

a=setup :passive 



SDP The SDP contains the set of answered content types supported by UE#2 in the accept-types 

attribute and indicates the maximum size message that can be received by UE#2 and allowed by 
the policy of network homel in the max-size attribute. 



41. 200 (OK) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.3-41 

S-CSCF#1 forwards the 200 (OK) response to P-CSCF#1. 
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Table A.4.3-41 : 200 (OK) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
Privacy: 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Supported 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 

a= 



42. 200 (OK) response (P-CSCF#1 to UE#1) - see example in table A.4.3-42 

P-CSCF#1 forwards the 200 (OK) response to UE#1 

Table A.4.3-42: 200 (OK) response (P-CSCF#1 to UE#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record-Route : <sip : asl . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 

<sip : pcscf 1 .visitedl .net : 75 31; lr;comp=sigcomp> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Supported 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 



43. ACK request (UE#1 to P-CSCF#1) - see example in table A.4.3-43 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 
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Table A.4.3-43: ACK request (UE#1 to P-CSCF#1) 



ACK sip: user2_publicl@home2 .net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr>, 

<sip : asl . homel . net ; lr> 
From: <sip :userl_publicl@homel .net>; tag=17182 8 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 ACK 
Content-Length: 



44. ACK request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.3-44 

The P-CSCF#1 forwards the ACK request to the S-CSCF#1. 

Table A.4.3-44: ACK request (P-CSCF#1 to S-CSCF#1) 



ACK sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Info : 

Route: <sip : scscfl .homel .net ; lr>, <sip : asl .homel .net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



45. ACK request (S-CSCF#1 to AS#1) - see example in table A.4.3-45 

The S-CSCF#1 forwards the ACK request to AS#1. 

Table A.4.3-45: ACK request (S-CSCF#1 to AS#1) 



ACK sip:user2 publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c7 


SIP/2.0 


Via: SIP/2. 0/UDP scscfl. homel. net ;branch=z9hG4bK344a65.1, SIP/2. 0/UDP 




pcscfl. visitedl. net;branch=z9hG4bK240f 34.1, SIP/2. 0/UDP 




[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 




Max-Forwards: 68 




Route: <sip : asl .homel .net ; lr> 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





46. Reserve IP-CAN bearer for media 

UE#1 reserves an IP-CAN bearer for the message session media component. 

47. TCP setup 

Originating UE#1 establishes a TCP connection using the IP -CAN bearers established in step 46 to the host 
address and port as specified in the MSRP URL received in the SDP Answer from AS#1. 

48. MSRP SEND (UE#1 to AS#1) - see example in table A.4.3-48 

The originating UE sends the first message over the MSRP session with a MSRP SEND request using the 
established TCP connection. 
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Table A.4.3-48: MSRP SEND (UE#1 to AS#1) 



MSRP 34kjf94 SEND 




To-path:msrp: // [7777 : : eee :ddd:ccc : aaa] : 3 92 7/s222 3 72 ; tcp 




From-path:msrp:// [5555: : aaa : bbb : ccc : ddd] : 2855/slll271; tcp 




Message-ID: 8822 




Byte-Range: 1-89/89 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members 


- Groucho Marx . 


34kjf94$ 





To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

49. MSRP SEND (AS#1 to AS#2) - see example in table A.4.3-49 

AS#1 forwards the first MSRP SEND request to AS#2 over the MSRP session using the estabHshed TCP 
connection. 

Table A.4.3-49: MSRP SEND (AS#1 to AS#2) 



MSRP shfsoi3 SEND 




To-path :msrp:// [9999: : ccc : aaa : bbb : ddd] : 3333/s317122 ; tcp 




From-path :msrp: // [7777 : : eee : ddd: ccc :aaa] : 3 92 7/s222 3 71; tcp 




Message-ID: 2832 




Byte-Range: 1-89/89 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members 


- Groucho Marx . 


shf soi3$ 





To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

50. MSRP SEND (AS#2 to UE#2) - see example in table A.4.3-50 

AS#2 forwards the first MSRP SEND request to UE#2 over the MSRP session using the estabhshed TCP 
connection. 

Table A.4.3-50: MSRP SEND (AS#2 to UE#2) 



MSRP 2oid4sf SEND 




To-path :msrp:// [5555: : eee : f f f : aaa : bbb] : 3335/s417121 ; tcp 




From-path :msrp:// [9999: : ccc : aaa : bbb : ddd] : 3333/s317121; tcp 




Message-ID: 3311 




Byte-Range: 1-89/89 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members 


- Groucho Marx . 


2oid4sf$ 
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To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

51. MSRP 200 (OK) response (UE#2 to AS#2) - see example in table A.4.3-51 

The receiving UE#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) 
response sent using the established TCP connection. 

Table A.4.3-51: MSRP 200 (OK) response (UE#2 to AS#2) 



MSRP 


2oid4sf 200 OK 














To-path :msrp: // [9999 : : ccc 


aaa :bbb 


ddd] 


:3333/s317121;t 


=P 


From 


-pathimsrp:// [5555: 


eee 


fff :aaa:bbb] : 3335/s417121 


; tcp 





2oid4sf2j32ri3$ 















52. MSRP 200 (OK) response (AS#2 to AS#1) - see example in table A.4.3-52 

AS#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to AS#1 
using the established TCP connection. 

Table A.4.3-52: MSRP 200 (OK) response (AS#2 to AS#1) 



MSRP 


shfsoi3 200 OK 














To-path :msrp: // [7777 : : 


see 


ddd 


ccciaaa] : 3927/s222371; t 


cp 


From- 


pathimsrp: // [9999 


: : ccc : aaa 


bbb 


ddd] :3333/s317122 


;tcp 




--hfsoi3$ 















53. MSRP 200 (OK) response (AS#1 to UE#1) - see example in table A.4.3-53 

AS#1 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to UE#1 
sent using the established TCP connection. 

Table A.4.3-53: MSRP 200 (OK) response (AS#1 to UE#1) 



MSRP 


34kjf94 200 OK 














To-path :msrp : // [555 : : aaa 


:bbb 


: ccc 


:ddd] 


:2855/slll271 


tcp 




From 


-pathimsrp: // [7777 : : 


eee : 


ddd: 


ccc:aaa] : 3927/s222372 ; t 


cp 





---34kjf94$ 















A.4.4 Establishing a session for session-based messaging with 
preconditions 

This signalling flow is not provided as it is the same as the session establishment flows with preconditions in 3GPP TS 
24.228 [4] except that the SDP contents are for setting up MSRP sessions over TCP rather than RTP sessions over 
UDP. 
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A.5 Flows demonstrating session-based messaging 
conferences 

A.5.1 User connecting into a messaging conference 



Visited Network 



UE#1 Home 
Network 



MRFC/AS Home Network 



UE#1 



P-CSCF 



S-CSCF 



l-CSCF 



HSS 



— 1.INVITE- 
-2. 100 Trying 



— 3. INVITE — 
-4. 100 Trying- 



5. Evaiuation of initiai 
Fiiter Criteria 



-14. 200 OK - 



1 5. Authorize QoS resources 



-16. 200 OK 

— 17.ACK ► 



21. Resource 
Reservation 



-18. ACK »■ 



— 6. iNViTE- 
-7. 100 Trying 



-13.200OK- 



-19. ACK ► 



. PSI location query 



-9. iNViTE- 



-10. 100 Trying - 



-1 2.200 OK- 



-20.ACK- 



■22. TCP setup" 



■23. SEND" 



■24. 200 OK" 



MRFC/AS 



IVIRFP 



1 1 . H.248 interaction to create 

conference connection resources for 

UE#1 



Figure A.5. 1-1 : User connecting into a messaging conference - network IVIRFC/AS is not located in 
user's home network - conference URI resolved by the terminating home network 
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Figure A.5. 1-1 shows an user calling into a messaging conference by using a conference URL The focus of that 
conference is at a MRFC/AS which are located in another network. The conference URl in this example cannot be 
resolved by the originating home network 



The details of the flows are as follows: 

1. INVITE request (UE to P-CSCF) - see example in table A.5.1-1 

A UE wants to join a messaging conference. For this purpose the UE is aware of the related conference URI 
that was obtained by means outside the present document (e.g. via other protocols, such as http). 

The originating UE creates a local MSRP URL, which can be used for communication for the messaging 
conference. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for 
the MSRP communication. 

The UE sends the INVITE request to the P-CSCF. 

Table A.5.1-1 : INVITE request (UE to P-CSCF) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip :pcscf 1 . visitedl .net : 7531; Ir ; comp=sigcomp> , <sip :orig@scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <sip : conf erencel@home2 .net> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 2855 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [5555 : : aaa : bbb : ccc : ddd] : 2855/slll271; tcp 

a=max-size : 131072 

a=msrp-cema 

a=setup : active 



SDP The SDP contains a set of content types supported by UE#1 and desired by the user at UE#1 for 

this session in the accept-types attribute and indicates the maximum size message that can be 
received by UE#1 in the max-size attribute. 
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2. 100 (Trying) response (P-CSCF to UE) - see example in table A.5.1-2 

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response. 

Table A.5.1-2: 100 (Trying) response (P-CSCF to UE) 



SIP/2.0 100 (Trying) response 




Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] 


: 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 


From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





3. INVITE request (P-CSCF to S-CSCF) - see example in table A.5.1-3 

The P-CSCF forwards the INVITE request to the S-CSCF. 

Table A.5.1-3: INVITE request (P-CSCF to S-CSCF) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip :pcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 
m= 
a= 



4. 100 (Trying) response (S-CSCF to P-CSCF) - see example in table A.5.1-4 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response. 

Table A.5.1-4: 100 (Trying) response (S-CSCF to P-CSCF) 



SIP/2.0 100 (Trying) 
Via: SIP/2. 0/UDP pcsc 


response 
f 1 .visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555: :aaa:bbb:ccc 


:ddd] :1357; 


comp= 


=sigcomp 


;branch=z9hG4bKnashds7 




From: 
















To: 
















Call-ID: 
















CSeq: 

Content-Length: 

















5. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 
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6. INVITE request (S-CSCF to I-CSCF) - see example in table A.5.1-6 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the INVITE request directly to the I-CSCF in the destination 
network. 

As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 



Table A.5.1-6: INVITE request (S-CSCF to I-CSCF) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net ; lr> 
P-Asserted-Identity: "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
a= 



7. 100 (Trying) response (I-CSCF to S-CSCF) - see example in table A.5.1-7 (related to table A.5.1-6) 

The I-CSCF responds to the INVITE request (6) with a 100 (Trying) response provisional response. 

Table A.5.1-7: 100 (Trying) response (I-CSCF to S-CSCF) 



SIP/2.0 100 (Trying) 
Via: SIP/2. 0/UDP scsc 


response 
f 1 .homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . 


visitedl .net ;branch= 


z9hG4bK240f34. 


1, SIP/2 


0/UDP 




[5555: : 


aaa :bbb : ccc 


:ddd] : 1357;comp=sigcomp 


;branch= 


29hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 

Content-Le 


ngth : 













8. Public service identity (PSI) location query 

The I-CSCF sends a query to the HSS to find out the MRFC/AS at which the conference has been created. 
The HSS responds with the address of the MRFC/AS at which the conference is hosted. The HSS responds 
with the address of the MRFC/AS. 

For detailed message flows see [5]. 
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9. INVITE request (I-CSCF to MRFC/AS) - see example in table A.5.1-9 

I-CSCF forwards the INVITE request to the MRFC/AS that was resolved during the PSI location query (8). 
The I-CSCF does not re-write the Request URL 

Table A.5.1-9: INVITE request (I-CSCF to MRFC/AS) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 



10. 100 (Trying) response (MRFC/AS to I-CSCF) - see example in table A.5.1-10 (related to table A.5.1-9) 

The MRFC/AS responds to the INVITE request (9) with a 100 (Trying) response provisional response. 

Table A.5.1-10: 100 (Trying) response (MRFC/AS to I-CSCF) 



SIP/2.0 100 (Trying) response 
Via: SIP/2. 0/UDP icscf2 s .home2 .net ;branch= 
scscfl. homel. net ;branch=z9hG4bK332b23.1, 


z9hG4bK871yl2.1, 
SIP/2. 0/UDP 


SIP/2. 


0/UDP 


pcscf 1 
[5555: 


visitedl .net ;branch=z 
aaa:bbb:ccc:ddd] :1357 


9hG4bK240f34.1, SIP/2. 0/UDP 
;comp=sigcomp;branch=z9hG4bKnashds7 




From: 
















To: 
















Call-ID: 
















CSeq: 

Content-Length: 















1 1 . H.248 interaction to create conference connection resources for UE#1 

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP. 

12. 200 (OK) response (MRFC/AS to I-CSCF) - see example in table A.5.1-12 (related to table A.5.1-9) 

The MRFC/AS sends a 200 (OK) response for the INVITE request containing SDP that indicates that the 
MRFC/AS has accepted the message session and listens on the MSRP TCP port returned in the path attribute 
in the answer for a TCP SETUP from the originating UE. The MRFC/AS sends a 200 (OK) response final 
response to the INVITE request (9) to the I-CSCF. 
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Table A.5.1-12: 200 (OK) response (M RFC/ AS to l-CSCF) 



orig-ioi=homel .net ; 
:a55 :b44 :C33 :d22] ; 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 .net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net; lr> 
P-Asserted-Identity : "Conference Server" <sip :mrf cl .home2 .net> 
P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; 

term- ioi=home2 . net 
P- Charging- Function- Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555: 

ecf= [555 5 : : If f : 2ee : 3dd : 4cc] ; ecf= [5555 : : 6aa : 7bb : Bcc : 9dd] 
Privacy: none 
From: 

To: <sip : conf erencel@home2 .net>; tag=314159 
Call-ID: 
CSeq: 

Contact : <sip : conf erencel®home2 . net> ; isf ocus 
Allow-Events : conference, pending-additions 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 
Content-Type: application/sdp 
Content-Length: (...) 



o=- 2987933623 2987933623 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 2855 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [9999 : : aaa: bbb: ccc :ddd] : 2855/s317122 ; tcp 

a=max-size : 32 76 8 

a=msrp-cema 

a=setup :passive 



SDP 



The SDP contains a set of offered content types supported by the MRFC/AS for this session in the 
accept-types attribute and indicates the maximum size message that can be received by the 
MRFC/AS in the max-size attribute. 
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13. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.5.1-13 

The I-CSCF sends a 200 (OK) response final response along the signalling path back to the S-CSCF. 

Table A.5.1-13: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term-ioi=home2 .net 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
a= 



14. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.5.1-14 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF. 

Table A.5.1-14: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl .net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c8 8 :d77 : e6 6] ; ccf = [5555 : : a5 5 :b44 : c3 3 : d22] 

ecf= [5555: : If f : 2ee : 3dd : 4cc] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Allow: 

Content-Type : 
Content - Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



15. Authorize QoS Resources 

The P-CSCF authorizes the resources necessary for this session. 
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16. 200 (OK) response (P-CSCF to UE) - see example in table A.5.1-16 

The P-CSCF forwards the 200 (OK) response final response including the media authorisation token to the 
session originator. 

Table A.5.1-16: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net : 75 31; lr;comp=sigcomp> 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow-Events : 

Allow: 

Content-Type : 

Content-Length : 



17. ACK request (UE to P-CSCF) - see example in table A.5.1-17 

The UE starts the media flow for this session, and responds to the 200( OK) response (16) with an ACK 
request sent to the P-CSCF. 

Table A.5.1-17: ACK request (UE to P-CSCF) 



ACK sip :conferencel®home2 .net : 2342 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip :pcscf 1 .visitedl .net : 7531; Ir ; comp=sigcomp> , <sip:scscfl .homel .net; lr> 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erencel@home2 . net> ; tag=314159 

Call-ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 127 ACK 

Content-Length: 



18. ACK request (P-CSCF to S-CSCF) - see example in table A.5.1-18 

The P-CSCF forwards the ACK request to the S-CSCF. 

Table A.5.1-18: ACK request (P-CSCF to S-CSCF) 



ACK sip : conf erence 


1 ©home 2 . 


net:2342 SIP/2.0 












Via: SIP/2. 0/UDP p 


cscf 1 .visitedl .net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555: :aaa:bbb: 


ccc :ddd] 


: 1357;COmp= 


=sigcomp 


;branch= 


z9hG4bKnashds7 




Max- Forwards : 69 


















Route: <sip:scscfl 


.homel .net; lr> 














From: 


















To: 


















Call-ID: 


















Cseq: 


















Content-Length: 



















19. ACK request (S-CSCF to I-CSCF) - see example in table A.5.1-19 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the ACK request directly to the 1-CSCF in the destination 
network. 

As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 
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Table A.5.1-19: ACK request (S-CSCF to l-CSCF) 



ACK sip : conference 


l@home2 . 


net 


2342 SIP/2.0 








Via: SIP/2. 0/UDP scscfl.homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . visitedl 


.net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc :ddd] 


: 13 57;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


Max- Forwards : 6 8 














From: 














To: 














Call-ID: 














Cseq: 














Content-Length: 















20. ACK request (I-CSCF to MRFC/AS) - see example in table A.5.1-20 

I-CSCF forwards the ACK request to the MRFC/AS that was resolved during the PSI location query (8). The 
I-CSCF does not re-write the Request URL 

Table A.5.1-20: ACK request (I-CSCF to MRFC/AS) 



ACK sip : conf erencel@home2 . 

Via: SIP/2. 0/UDP icscf2_s. 

scscf 1 .homel .net /branch 


net:2342 SIP/2.0 
home2 . net ; branch= 
=z9hG4bK332b23.1, 


z9hG4bK871yl2.1, 
SIP/2. 0/UDP 


SIP/2. 


0/UDP 


pcscf 1 .visitedl 
[5555: :aaa:bbb: 
Max- Forwards : 6 7 


. net ;branch=z9hG4bK240f 34.1, SIP/2 
ccc :ddd] : 13 57;comp=sigcomp;branch= 


.0/UDP 
z9hG4bKnashds7 




From: 














To: 














Call-ID: 














Cseq: 
Content-Length: 















21. Reserve IP-CAN bearer for media 

The UE reserves an IP -CAN bearer for the message session media component. 

22. TCP setup 

Originating UE establishes a TCP connection using the IP-CAN bearers established in step 21 to the host 
address and port as specified in the MSRP URL received in the SDP Answer from MRFC/AS. 

23. MSRP SEND request (UE to MRFP) - see example in table A.5.1-23 

The originating UE sends the first message over the MSRP session with an MSRP SEND request using the 
established TCP connection. 

Table A.5.1-23: MSRP SEND request (UE to MRFP) 



MSRP a97ghjut SEND 

To-path:msrp:// [9999: : ccc : aaa : bbb : ddd] : 2855/s317122 ; tcp 

From-path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 2855/slll271; tcp 

Message-ID: 9972 

Byte-Range: 1-77/77 

Content-Type: "text/plain" 

those are my principles. If you don't like them I have others - Groucho Marx. 

a97ghjut$ 



To-path: The sender" s remote path 

From-path: The sender" s local URL 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 
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24. MSRP 200 (OK) response (MRFP to UE) - see example in table A.5.1-24 

The MRFP acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response using the 
established TCP connection. 

Table A.5.1-24: MSRP 200 (OK) response (MRFP to UE) 



MSRP a97ghjut 200 OK 

To-path:msrp:// [9999: : ccc : aaa : bbb : ddd] : 2855/s317122 ; tcp 
From-path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 2855/slll271; tcp 
a97ghjut$ 



A. 5. 2 MRFC/AS invites a user to a messaging conference 

Figure A.5.2-1 shows an MRFC/AS inviting a user to a messaging conference. The invitation is sent as a result of 
userl @homel.net sending a REFER request to the MRFC/AS. The MRFC/AS is located in a different network than 
user's S-CSCF. The flows for inviting a user to a conference using REFER are shown in TS 24.147 [10]. 



£75/ 



3GPP TS 24.247 version 10.4.0 Release 10 



68 



ETSI TS 124 247 VI 0.4.0 (2012-10) 



UE#1 Home Network 



UE#2 Home Network 



MRFP 



M RFC/AS 



UE#2 Visited Network 



l-CSCF 



-1. INVITE > 



-2. 100 Trying- 



S-CSCF 



S.HSSquery 



-16. 200 OK- 



—4. INVITE *■ 

-5. 100 Trying — 



P-CSCF 



6. Evaluation of 
initial Filter Criteria 



< 14. 200 OK- 



< 15.200OK- 



-17. ACK- 



20. H.248 interaction to create 

conference connection 

resources for UE#2 



—7. INVITE > 

-8. 100 Trying — 



UE#2 



9. Authorize QoS 
resources 



-18. ACK- 



21. TCP setupi 



■ 22. SENDi 



■ 23. 200 OKi 



-10. INVITE ► 



-11. 100 Trying 



12. Resource 
Reservation 



4 13.200OK- 



-19. ACK- 




Figure A.5.2-1 : MRFC/AS inviting a user to a messaging conference - lUIRFC/AS routes directly to I- 

CSCF 

The details of the flows are as follows: 
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1. INVITE request (MRFC/AS to I-CSCF) - see example in table A,5.2-l 

In this example, the MRFC/AS is capable of resolving the terminating users I-CSCF address for this request. 
As a result of a DNS query, it has received the address of the I-CSCF as the next hop. 

The MRFC/AS invites a user to a messaging conference as it received a REFER request from another user. 

The MRFC/AS creates a local MSRP URL, which can be used for communication for the messaging 
conference. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for 
the MSRP communication. 

Table A.5.2-1 : INVITE request (MRFC/AS to I-CSCF) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP mrfcl.homel.net;branch=z9hG4bK23273846 

Max- Forwards : 70 

P-Asserted- Identity : <sip : conf erencelomrf cl .homel .net> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <sip : conf erencelomrf cl .homel .net>; tag=17182 8 

To : <sip : user2_publicl@home2 . net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Referred- By : <sip :userl_publicl@homel .net> 

Contact : <sip : conf erencelomrf cl . homel . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 

Allow-Events : conference, pending-additions 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : abc : def : abc : def 

s = - 

c = IN IP6 5555 : :abc:def :abc:def 

t = 

m=message 2855 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [5555 : : abc : def : abc : def ] : 2855/slll271; tcp 

a=max-size : 32768 

a=msrp-cema 

a=setup : active 



SDP The SDP contains a set of content types supported by the MRFC/AS for this session in the accept- 

types attribute and indicates the maximum size message that can be received by the MRFC/AS in 
the max-size attribute. 



2. 100 (Trying) response (I-CSCF to MRFC/AS) - see example in table A.5.2-2 

The I-CSCF responds to the INVITE request with a 100 (Trying) provisional response. 

Table A.5.2-2: 100 (Trying) response (I-CSCF to MRFC/AS) 



SIP/2.0 100 Trying 

Via: SIP/2 . 0/UDP conf erencelomrf cl .homel .net ;branch=z9hG4bK2 32 73 84 6 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



3. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228[11]. 
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4. INVITE request (I-CSCF to S-CSCF) - see example in table A.5.2-4 

The INVITE request is forwarded to the S-CSCF. 

Table A.5.2-4: INVITE request (I-CSCF to S-CSCF) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
Max- Forwards : 6 9 
P-Asserted- Identity : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Ref erred-By : 
Contact : 
Allow: 

Allow- Events : 
Content-Type : 
Content-Length: (...) 



o= 

s= 
c= 

t= 

m= 
a= 
a= 
a= 



5. 100 (Trying) response (S-CSCF to I-CSCF) - see example in table A.5.2-5 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response. 

Table A.5.2-5: 100 (Trying) response (S-CSCF to I-CSCF) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf2 .home2 .net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



6. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

7. INVITE request (S-CSCF to P-CSCF) - see example in table A.5.2-7 

S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the P-CSCF 
assigned for UE#2 and routes message there. 
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Table A.5.2-7: INVITE request (S-CSCF to P-CSCF) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

icscf2.home2.net;branch=z9hG4bK241dl7.2, SIP/2 . 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
Max- Forwards : 68 

Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Ref erred-By : 
Contact : 
Allow: 

Allow- Events : 

P- Called- Party- ID : <sip :user2_publicl@home2 .net> 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



100 (Trying) response (P-CSCF to S-CSCF) - see example in table A.5.2-8 

The P-CSCF responds to the INVITE request (6) with a 100 (Trying) provisional response. 

Table A.5.2-8: 100 (Trying) response (P-CSCF to S-CSCF) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl. homel. net ;branch=z9hG4bK23273846 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



9. Authorize QoS resources 

The P-CSCF authorizes the resources necessary for this session. 
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10. INVITE request (P-CSCF to UE#2) - see example in table A.5.2-10 

P-CSCF forwards the request to UE#2 including the Media Authorisation token. 

Table A.5.2-10: INVITE request (P-CSCF to UE#2) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK240f 34 . 1 SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Max- Forwards : 6 7 

Record- Route : <sip :pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Ref erred-By : 
Contact : 
Allow: 

Allow- Events : 
P-Called-Party-ID: 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 



1 1. 100 (Trying) response (UE#2 to P-CSCF) - see example in table A.5.2-11 

UE#2 responds to the INVITE request (10) with a 100 (Trying) provisional response. 

Table A.5.2-11 : 100 (Trying) response (UE#2 to P-CSCF) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 .visited2 . net : 5088 ; comp=si 
scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2 


jcomp;branch= 
0/UDP 


z9hG4bK240f34 


1 SIP/2 


0/UDP 


icscf 2 . home2 . net 


;branch= 


=z9hG4bK241dl7.2 


SIP/2 


0/UDP 








mrfcl . homel . net ; 


branch=z9hG4bK232 73 84 6 












From: 
















To: 
















Call-ID: 
















CSeq: 
Content-Length: 

















12. Resource reservation 

After determining the media streams, UE#2 initiates the reservation procedures for the resources needed for 
this session. 



13. 200 (OK) response (UE#2 to P-CSCF) - see example in table A.5.2-13 (related to table A.5.2-10) 

After reserving an IP -CAN bearer for the message session media component the receipt of the MSRP 200 
(OK) response to the MSRP VISIT request, the terminating UE#2 sends a 200 (OK) response for the INVITE 
request containing SDP that indicates that UE#2 has successfully visited AS#2, accepted the message session 
and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP from the 
MRFC/AS. 
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Table A.5.2-13: 200 (OK) response (UE#2 to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net : 5088 ;comp=sigcomp;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record- Route : <sip ipcscf 2 . visited2 .net : 50 8 8 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From: 

To: <sip :user2_publicl@home2 .net>; tag=314159 
Call-ID: 

CSeq: 127 INVITE 
Supported: gruu 
Contact : <sip: user2_publicl®home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=message 2855 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp:// [5555: : eee : f f f : aaa : bbb] : 2855/s417121; tcp 

a=max-size : 65536 

a=msrp-cema 

a=setup :passive 



SDP The SDP contains a set of offered content types supported by UE#2 and desired by the user at 

UE#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be received by UE#2 in the max-size attribute. 



14. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.5.2-14 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.5.2-14: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2.net , • branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

icscf2.home2.net;branch=z9hG4bK241dl7.2, SIP/2 .0/UDP 

mrfcl .homel. net ;branch=z9hG4bK23273846 
Record- Route : <sip :pcscf 2 . visited2 .net;lr>, <sip:scscf2 .home2 .net ; lr> 
P-Asserted-Identity : "John Smith" <sip :user2_publicl@home2 .net> 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
a= 
a= 
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15. 200 (OK) response (S-CSCF to I-CSCF) - see example in table A.5.2-15 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to I-CSCF. 

Table A.5.2-15: 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
Record-Route : 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term- ioi=home2 . net 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 :d77 : e66] ; ccf = [5555 : : a55 : b44 : c33 : d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4cc] ; ecf= [5555: : 6aa : 7bb : Sec : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 



16. 200 (OK) response (I-CSCF to MRFC/AS) - see example in table A.5.2-16 

The I-CSCF forwards the 200 (OK) response final response to the session originator. 

Table A.5.2-16: 200 (OK) response (I-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrf cl . homel . net ;branch=z9hG4bK23273846 

Record-Route : 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 
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17. ACK request (MRFC/AS to S-CSCF) - see example in table A.5.2-17 

The MRFC/AS responds to the 200 (OK) response (16) with an ACK request sent to the S-CSCF. 

Table A.5.2-17: ACK request (MRFC/AS to S-CSCF) 



ACK sip:user2 publicl@home2 . net ;gr 


=urn 


:uuid:2ad8 95 0e-4 8a5- 


4a74- 


8d99 


-ad76 


cc7fc74 


;comp=sigcomp SIP/2.0 


















Via: SIP/2. 0/UDP mrfcl.homel 


net;b 


ranc 


ti=z9hG4bK23273846 










Max- Forwards : 70 


















Route: <sip : scscf 2 .home2 .net 


-lr>, 


<sip 


:pcscf 2 


. visited2 .net 


;lr> 








From: <sip : conf erencelomrf cl 


homel 


.net 


>; tag= 


171828 










To: <sip:user2 publicl@home2 


net>; 


tag= 


314159 












Call -ID: Cb03a0s09a2sdfglkj49033 3 
















Cseq: 127 ACK 


















Content-Length: 



















18. ACK request (S-CSCF to P-CSCF) - see example in table A.5.2-18 

The S-CSCF forwards the ACK request to the P-CSCF. 

Table A.5.2-18: ACK request (S-CSCF to P-CSCF) 



ACK sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, 


SIP/2. 0/UDP 


mrfcl. homel. net ;branch=z9hG4bK23273846 




Max- Forwards : 69 




Route : <sip:pcscf 2 . visited2 .net; lr> 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





19. ACK request (P-CSCF to UE#2) - see example in table A.5.2-19 

The P-CSCF forwards the ACK request to the UE#2. 

Table A.5.2-19: ACK request (P-CSCF to UE#2) 



ACK sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 






Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5088 ; comp=sigcomp;branch= 


z9hG4bK240f34.1, 


SIP/2. 0/UDP 


scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2. 0/UDP 






mrfcl. homel. net ;branch=z9hG4bK23273846 






Max-Forwards: 68 






From: 






To: 






Call-ID: 






Cseq: 






Content-Length: 







20. H.248 interaction to create conference connection resources for UE#2 

MRFC initiates a H.248 interaction to create an connection point for UE#2 in MRFP. 

21. TCP setup 

MRFP establishes a TCP connection using the IP-CAN bearers established in step 12 to the host address and 
port as specified in the MSRP URL received in the SDP Answer UE#2. 

22. MSRP SEND request (MRFP to UE#2) - see example in table A.5.2-22 

The MRFP sends the first message over the MSRP session with an MSRP SEND request using the established 
TCP connection. 
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Table A.5.2-22: MSRP SEND request (MRFP to UE#2) 



MSRP y5 6hkseg SEND 




To-path:msrp:// [5555: : eee : f f f : aaa : bbb] : 2855/s417121 ; tcp 




From-path:msrp:// [5555: : abc : def : abc : def ] : 2855/slll271; tcp 




Message-ID: 10568 




Byte-Range: 1-89/89 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members 


- Groucho Marx . 


y56hkseg$ 





To-path: The sender" s remote path 

From-path: The sender" s local URL 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

23. MSRP 200 (OK) response (UE#2 to MRFP) - see example in table A.5.2-23 

The terminating UE acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response 
using the established TCP connection. 

Table A.5.2-23: MSRP 200 (OK) response (UE#2 to MRFP) 



MSRP 


y56hkseg 200 OK 














To-path :msrp: // [5555 : : 


see 


f f f : aaa 


bbb] 


:2855/s417121 


tcp 


From 


-path:msrp: // [5555 


: -.ai 


c:def 


abc:def] : 2855/slll271; tcp 























£75/ 



3GPP TS 24.247 version 10.4.0 Release 10 



77 



ETSI TS 124 247 VI 0.4.0 (2012-10) 



Annex B (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


2003-06 










Version 0.0.1 : Initial version for discussion 




0.0.1 


2003-06 


CN#31 








Version 0.0.2: Title and text changed in order to reflect that 
Messaging is a service. 


N1- 

03112 

3 


N1- 

03128 

1 


2003-09 










Version 0.1 .0: Title changed 


0.0.2 


0.1.0 


2003-12 










Version 0.2.0: Incorporated the following CRs as approved at 

CN#32 meeting: 

N1 -031 676: Message Sessions in IMS -Call Flow 

N1 -031677: Immediate Messaging - Call Flow reference to 24.228 

N1 -031 722: Message Sessions in IMS -Text (created Annex B) 

N1 -031 723: Immediate Messaging -Text 

Additionally the editor took the freedom to change the heading 
formats in subclause B.5. Also the title <void> of subclause B.5 
was replaced with the title of clause 5 in the main part of the text 
and subclauses B.5.1 and B.5. 2 were added (both <void>). 


0.1.0 


0.2.0 


2003-12 










Version 0.2.1 : Including minor issues that were left out by mistake 
when creating version 0.2.0 


0.2.0 


0.2.1 


2004-01 










Version 0.3.0: Incorporated the following CRs as approved at 

CN#32bis meeting: 

N1 -0401 51 - Message Session in IMS 

N1 -0401 89 - Deletion of imported and unused Definitions 

N1 -0401 97 - UE to UE message session flow 

N1 -0401 98 - Message Session Initiation - mobile originating case 

N1 -0401 99 - Message Session Initiation - mobile terminating case 

N1 -040200 - Use of MESSAGE versus MSRP 


0.2.1 


0.3.0 


2004-01 










Version 0.3.1: Including N1 -040200, that was left out (although 
listed) by mistake when creating version 0.3.0 


0.3.0 


0.3.1 


2004-02 










Version 0.4.0: Incorporated the following CRs as approved at 
CN1 #33 meeting: 

- N1 -040261 - Update of Scope 

- N 1-040262 - Correction of Flows 

- N 1-040280 - Editorial Changes 

- N1 -040306 - Corections to Annex A. 4. 3 

- N1 -040307 - Corrections to Annex B 

- N1 -040426 - SDP for session-based messaging 

- N1-040429 - Corrections to Annex A.I - A.4.2 

- N1 -040486 - Definition of MSRP Role for AS and MRFP 

- N1 -040488 - Session-based Messaging with Intermediate Node 
FlowA.4.3 


0.3.1 


0.4.0 


2004-02 










Version 0.4.1 : Added subclause 9.2.2, which was missing from last 
update. Minor editorials 


0.4.0 


0.4.1 


2004-04 










Version 0.5.0: Incorporated the following CRs as approved as 

CN1#33bis meeting: 

-N1 -040561 -MSRP in AS 

- N1 -040648 - Editorial changes to Annex A 

- N1 -040738 - MSRP terminating UE hosting flow 
as well as minor editorial changes 


0.4.1 


0.5.0 


2004-05 










Version 1 .0.0: Incorporated the following CRs as approved during 
CN1 #34 meeting: 

- N1 -041 038 - Shifting Material from Annex B to main body 

- N1 -041 036 - Corrections to Message Sessions Flows 

- N1 -041 040 -Ut for Messaging 

- N1 -040850 - Correction of signalling flow example 

- N1 -041 037 -Establishing a session with active intermediate 
nodes, with originating UE hosting, and without SBLP 

- N1-041 039 - Addition of Note to 5.3.1 .1 

- several smaller editorial changes 

Note: the material was first shifted from Annex B to the main body 
(approved CR in N1 -041 038), all CRs that were written against 
material in Annex B were afterwards applied against the material in 
the main body. 


0.5.0 


1.0.0 


2004-05 










Version 1 .0.1 produced to correct smaller editorial mistakes. 


1.0.0 


1.0.1 


2004-06 










Version 1 .1 .0 produced as outcome of CN#34bis meeting in 
Helsinki, Finland. Todc N1 -041 172 (Changes in MSRP) and 


1.0.1 


1.1.0 



£75/ 



3GPP TS 24.247 version 10.4.0 Release 10 



78 



ETSI TS 124 247 VI 0.4.0 (2012-10) 













smaller editorial changes incorporated. 






2004-08 










Version 1 .2.0 produced as outcome CN#35 meeting in Sophia 
Antipolis, France. Tdoc N1 -041 585 (AS section) and smaller 
editorial changes incorporated. 


1.1.0 


1.2.0 


2004-11 










Version 6.0.0 produces as outcome of CN#36 meeting in Seoul, 

South Korea. The following documents were incorporated: 

N1 -041 71 4 -deletion of Intro claus 

N1 -041 71 6 - Terminology alignment 

N1 -041 989 - Data Manipulation for IMS Messaging in Rel-6 

N1 -041 995 - Session establishment for session-mode messaging 

N1 -041 996 - Session-based messaging conferences 

N1 -041 997 -subclause 8 rework 

N1 -041 998 - general subclause in participant section 

N1 -041 999 -subclause 9 rework 

N1 -042001 - Participant in immediate messaging 

N1 -0421 14 -subclause 10 rework 

N1-0421 15 -subclause 6 rework 


1.2.0 


2.0.0 


2004-12 


CN-26 


NP-040611 






Version 2.0.0 is approved and the TS is brought under the change 
control. As an erroneous v6.0.0 is presented in CN-26, the first 
officially published version is 6.0.1. 


2.0.0 


6.0.1 


2005-03 


CN-27 


NP-050073 


Oil 


1 


Corrections to Message Session Flows to align with draft-ietf- 
simple-message-sessions-09 


6.0.1 


6.1.0 


2005-03 


CN-27 


NP-050073 


008 


1 


Alignment between TS 23.228/ TS 22.340 and TS 24.247 for 
immediate messaging 


6.0.1 


6.1.0 


2005-03 


CN-27 


NP-050073 


001 


1 


Resolution of references to 24.228 


6.0.1 


6.1.0 


2005-03 


CN-27 


NP-050073 


003 




MESSAGE to unregistered user 


6.0.1 


6.1.0 


2005-03 


CN-27 


NP-050073 


010 


2 


Removing CPCP from 24.247 


6.0.1 


6.1.0 


2005-03 


CN-27 


NP-050075 


009 


2 


Clarifications to TS 24.247 subclause 9.3 


6.0.1 


6.1.0 


2005-03 


CN-27 


NP-050075 


002 


3 


MESSAGE to multiple recipients 


6.0.1 


6.1.0 


2005-03 


CN-27 


NP-050075 


007 


2 


Alignment between TS 22.340 and on TS 24.247 for "is 
composing" 


6.0.1 


6.1.0 


2005-06 


CP-28 


CP-050060 


13 


1 


List server - sending requests 


6.1.0 


6.2.0 


2005-06 


CP-28 


CP-050060 


15 


1 


Adding of reference TS 26.241 to TS 24.247 


6.1.0 


6.2.0 


2005-06 


CP-28 


CP-050060 


16 


1 


Corrections to Message Session Flows to Align with draft-IETF- 
simple-message-sessions-1 


6.1.0 


6.2.0 


2005-09 


CP-29 


CP-050359 


17 




Corrections to TS 24.247 to align with draft-ietf-simple-message- 
sessions-1 1 


6.2.0 


6.3.0 


2005-12 


CP-30 


CP-050544 


18 


1 


Call flow corrections 


6.3.0 


6.4.0 


2005-12 


CP-30 


CP-050544 


19 




Corrections to TS 24.247 to align with Draft-ietf-simple-message- 
sessions12 


6.3.0 


6.4.0 


2006-03 


CP-31 


CP-060110 


20 




Corrections to references in TS 24.247 to align with draft-ietf- 
simple-message-sessions-13 and draft-ietf-sipping-uri-list- 
message-06 


6.4.0 


6.5.0 


2006-09 


CP-33 


CP-060504 


22 




Removal of Editor's notes in 24.247 


6.5.0 


6.6.0 


2006-11 


CP-34 


CP-060655 


23 


1 


Correction of the i-d name for Multiple-Recipient MESSAGE 
Requests in the Session Initiation Protocol (SIP 


6.6.0 


6.7.0 


2006-11 


CP-34 


CP-060661 


24 


2 


Addition of MSRP file transfer 


6.7.0 


7.0.0 


2007-03 


CP-35 


CP-070130 


26 




IETF reference corrections 


7.0.0 


7.1.0 


2007-06 


CP-36 


CP-070430 


27 




File transfer 


7.1.0 


7.2.0 


2007-12 


CP-38 


CP-070788 


32 




IETF reference updates 


7.2.0 


7.3.0 


2007-12 


CP-38 


CP-070810 


29 




Incorporation of roles relating draft-ietf-consent-framework 


7.3.0 


8.0.0 


2008-03 


CP-39 


CP-080140 


0033 


1 


Messaging references 


8.0.0 


8.1.0 


2008-12 


CP-42 


CP-080854 


0035 




Addition of media control for session-based messaging 


8.1.0 


8.2.0 


2008-12 


CP-42 


CP-080841 


0038 




Reference updates (release 6 ietf dependencies) 


8.1.0 


8.2.0 


2008-12 


CP-42 


CP-080846 


0042 


1 


Corrections of reference and flows in 24.247 


8.1.0 


8.2.0 


2008-12 


CP-42 








Editorial cleanup by MCC 


8.1.0 


8.2.0 



£75/ 



3GPP TS 24.247 version 10.4.0 Release 10 



79 



ETSI TS 124 247 VI 0.4.0 (2012-10) 



2009-06 


CP-44 


CP-090424 


0044 


1 


Alternative connection model for MSRP 


8.2.0 


8.3.0 


2009-12 


CP-46 








Upgrade to Rel-9 


8.3.0 


9.0.0 


2010-06 


CP-48 


CP-1 00351 


0046 


1 


MSRP allignment 


9.0.0 


9.1.0 


2010-12 


CP-50 


CP-1 00726 


0050 


1 


Inclusion of file transfer attributes 


9.1.0 


9.2.0 


2010-12 


CP-50 


CP-1 00874 


0052 


2 


Reference update: draft-ietf-simple-msrp-sessmatch & draft-ietf- 
simple-msrp-acm 


9.1.0 


9.2.0 


2011-03 


CP-51 


CP-1 101 72 


0054 




Reference update: draft-ietf-simple-msrp-sessmatch & draft-ietf- 
simple-msrp-acm 


9.2.0 


9.3.0 


2011-03 


CP-51 








Upgrade to Rel-10 


9.3.0 


10.0.0 


2011-06 


CP-52 


CP-1 10454 


0057 




Reference update: RFC 6135 


10.0.0 


10.1.0 


2011-09 


CP-53 


CP-1 10662 


0060 


1 


Reference update: draft-ietf-simple-msrp-sessmatch 


10.1.0 


10.2.0 


2011-12 


CP-54 


CP-1 10864 


0066 


1 


Reference update: draft-ietf-simple-msrp-cema 


10.2.0 


10.3.0 


2012-09 


CP-57 


CP-1 20573 


0069 


1 


Reference update: draft-ietf-simple-msrp-cema 


10.3.0 


10.4.0 



£75/ 



3GPP TS 24.247 version 10.4.0 Release 10 



80 



ETSI TS 124 247 VI 0.4.0 (2012-10) 



History 



Document history 


VIO.0.0 


April 2011 


Publication 


VIO.1.0 


June 2011 


Publication 


VIO.2.0 


October 201 1 


Publication 


VIO.3.0 


January 2012 


Publication 


VIO.4.0 


October 2012 


Publication 



£75/ 



